[Tcpick-project] Mac OS X 64bit woes

[Tobia C. <tob...@gm...>]

Hi all

I've always had trouble running tcpick on OS X, and was left with unwieldy substitutes such as Wireshark ;-)

Finally I took the time to debug it:

$ ./configure
$ make
$ sudo make install

$ sudo gdb tcpick 

(gdb) run -i en0 -p -yP
Starting program: /usr/local/bin/tcpick -i en0 -p -yP
Reading symbols for shared libraries ++........................ done
Starting tcpick 0.2.1 at 2011-11-05 19:28 CET
Timeout for connections is 600
tcpick: listening on en0
.
.
[snip random traffic]
.
.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000723ebbd0
0x00007fff8c1b44f0 in strlen ()
(gdb) bt
#0  0x00007fff8c1b44f0 in strlen ()
#1  0x00007fff8c1558c3 in __vfprintf ()
#2  0x00007fff8c15418e in vfprintf_l ()
#3  0x00000001000042a0 in color (attr=1051872, fg=1916690608, out=0x10000596a, fmt=0x10000596a " %s:%s ") at colors.c:42
#4  0x00000001000020fa in display_status (out=0x7fff723e54e8, conn=0x100100c30, status=SYN_SENT) at display.c:108
#5  0x0000000100002c27 in status_switch [inlined] () at /Users/toby/src/tcpick-0.2.1/src/tracker.c:38
#6  0x0000000100002c27 in newconn (prev_ring=0x100100b80) at tracker.c:87
#7  0x0000000100003e50 in verify () at verify.c:139
#8  0x0000000100002857 in got_packet (useless=0x7fff723e54e8 "c;?", hdr=0x2c, packet=0x100007d90 "8?\a") at loop.c:101
#9  0x000000010001bea9 in pcap_read_bpf ()
#10 0x000000010001cd10 in pcap_loop ()
#11 0x0000000100003230 in main (argc=1916687592, argv=0x32ffffffff) at tcpick.c:264
(gdb) f 4
#4  0x00000001000020fa in display_status (out=0x7fff723e54e8, conn=0x100100c30, status=SYN_SENT) at display.c:108
108		color( c_CLIENTNAME_STATUS, out, " %s:%s ",
(gdb) p getportname(conn->client.port)
$2 = 0x100100ce0 "52906"
(gdb) p lookup(conn->client.ip)
$3 = 0x7fff723ebbd0 "192.168.7.100"
(gdb) p (char *)inet_ntoa(conn->client.ip)
$8 = 0x7fff723ebbd0 "192.168.7.100"


So tcpick crashes when printing the status line, in display_status().

display_status() calls color() with a fmt of " %s:%s " and two perfectly valid va_args: the strings returned by getportname() and by lookup(), the latter being inet_ntoa()'s static buffer.

Then, deep inside vfprintf(), some strlen() fails on the address 0x723ebbd0, which doesn't exist, but looks suspiciously similar to said static buffer at 0x7fff723ebbd0.

I tried inserting a strcpy() to my own static buffer in the code. This time strlen() fails on 0x73d0, where my static buffer was at 0x1000073d0.

What's going on here? My guess is that some piece of code inside the C library is casting the string pointers to 32bit, thereby losing the most significant half:

0x00007fff723ebbd0
0x00000001000073d0
          ^^^^^^^^

As to what damnable piece of code is doing so and why, I don't have a clue.

But at least it pointed me to the workaround: compiling tcpick as a 32bit executable.

$ CFLAGS=-m32 ./configure
$ make
$ sudo make install

You might want to put it in the README or on the website, or even make autoconf do it by default when it's on OS X, until someone figures out this riddle.


Tobia