Author here. Part 2 will be coming soon.

If you would like the immersive experience - try this at the mac terminal:

echo i860 | grep --color -e i860 -e i86

Yep, and the crash reporter gives:

  Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
  0   libsystem_platform.dylib      	0x00007fffxxxxxxxx _platform_memchr$VARIANT$Haswell + 101
  1   libsystem_c.dylib             	0x00007fffxxxxxxxx __sfvwrite + 268
  2   libsystem_c.dylib             	0x00007fffxxxxxxxx fwrite + 142
  3   grep                          	0x00000001xxxxxxxx 0x10xxxxxxx + 13606
  4   grep                          	0x00000001xxxxxxxx 0x10xxxxxxx + 12465
  5   grep                          	0x00000001xxxxxxxx 0x10xxxxxxx + 8190
  6   libdyld.dylib                 	0x00007fffxxxxxxxx start + 1

A different version from yours though:

  what /usr/bin/grep
    PROGRAM:grep  PROJECT:bsdgrep-17

Is it possible that you're using Yosemite and TFA uses Mavericks? I have the same bsdgrep-16 on Mavericks.

Yep - I'm on 10.9.5

yep, 10.10.2 here

I'm running 10.7.5 and get no crash. Because I have GNU grep, it seems.

  % echo i860 | grep --color -e i860 -e i86
  i860
  % uname -a
  Darwin xebulon.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
  % grep --version
  grep (GNU grep) 2.5.1
     ...
  % which grep
  /usr/bin/grep

It looks like 2.5.1 was released on 29-Oct-2004.

Great read.. even prompted me to order "The Linux Programmer's Toolbox" from the author's affiliate link. For me there is no other way to REALLY learn about operating systems or hacking in general without tackling such problems that force you to dig more the further you look . This is the reason I prefer Dtrace as my investigative tool of choice and FreeBSD as my base OS for my side projects. Combined they allow one to see and investigate problems to a much deeper level without the severe overhead of other tools and understand the practical workings of a Unix derived OS without being a kernel hacker.

Thanks for the positive feedback and the contribution, I appreciate it. It's a good book :)

It's certainly rather surprising to see that colouring the output would cause such different (and buggy) behaviour - the number of matches shouldn't be affected by whether the output should be coloured or not... I would look carefully at how the execution flow diverges between the presence and absence of the --color option.

On your Mac the stack trace hints that the bug is due to a bad pointer/offset/size being passed to fwrite() but in the debug builds it looks like it's in the fastcmp() function. Is this the descrepancy you're talking about in the final paragraph?