

Tracking down a segfault in grep - loadzero
http://blog.loadzero.com/blog/tracking-down-a-segfault-in-grep/

======
loadzero
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

~~~
0x0
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

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

~~~
loadzero
Yep - I'm on 10.9.5

~~~
0x0
yep, 10.10.2 here

------
joshbaptiste
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.

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

------
userbinator
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.

------
rian
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?

