Tracking down a segfault in grep(blog.loadzero.com)
blog.loadzero.com
Tracking down a segfault in grep
http://blog.loadzero.com/blog/tracking-down-a-segfault-in-grep/
10 comments
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
what /usr/bin/grep
PROGRAM:grep PROJECT:bsdgrep-17I'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
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?
If you would like the immersive experience - try this at the mac terminal:
echo i860 | grep --color -e i860 -e i86