Re: Building tcpdump 3.8.3 undex Solaris 2.9

[Greg Earle <earle () isolar dyndns org>]

Speaking of tcpdump 3.8.3 and Solaris 9 ...

Has anyone built a 64-bit libpcap.a and 64-bit tcpdump binary
with Sun's Forte 6 compiler?

It builds fine (with CFLAGS/CXXFLAGS/LDFLAGS = "-g -xarch=v9a"), but
dies on startup:

zorro:1:126 [/usr/local/src/networking/tcpdump/tcpdump-3.8.3] # dbx -I. 
\
-I../libpcap tcpdump
Use the `help' command for more information.
Reading tcpdump
Reading ld.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libmp.so.2
Reading libc_psr.so.1
(/opt/SUNWspro/WS6U2/bin/sparcv9/dbx) run
Running: tcpdump
(process id 768)
dbx: warning: undefined type number (8,40) at \
/usr/local/src/networking/tcpdump/tcpdump-3.8.3/tcpdump:scanner.c stab 
#93
hints:(8,40),
assuming type `int {assumed}'
signal SEGV (no mapping at the fault address) in pcap__scan_bytes
at line 1053 in file "scanner.l"
dbx: warning: "scanner.l" has only 420 lines
(/opt/SUNWspro/WS6U2/bin/sparcv9/dbx) where
=>[1] pcap__scan_bytes(bytes = 0x1001e7fc0 "", len = 0), line 1053 in 
"scanner.l"
  [2] pcap__scan_string(yy_str = 0x1001e7fc0 ""), line 1025 in 
"scanner.l"
  [3] lex_init(buf = 0x1001e7fc0 ""), line 353 in "scanner.l"
  [4] pcap_compile(p = 0x10037f3a0, program = 0xffffffff7ffff7e8, buf = 
(nil), optimize = 1, mask = 4294967040U), line 342 in "gencode.c"
  [5] main(argc = 1, argv = 0xffffffff7ffff918), line 731 in "tcpdump.c"

"scanner.c" was created with flex 2.4.5.  ("grammar.c" was created with
bison 1.875, but I doubt that matters.)

I think the crash is happening in "banner.c"/yy_scan_bytes() at

        /* Get memory for full buffer, including space for trailing 
EOB's. */
        n = len + 2;
***==>  buf = (char *) yy_flex_alloc( n );
        if ( ! buf )
                YY_FATAL_ERROR( "out of dynamic memory in 
yy_scan_bytes()" );

                for ( i = 0; i < len; ++i )
                        buf[i] = bytes[i];

        buf[len] = buf[len+1] = YY_END_OF_BUFFER_CHAR;

because before the yy_flex_alloc(), "buf" is OK:

(/opt/SUNWspro/bin/WS6U2/bin/sparcv9/dbx) print buf
buf = 0x10002716b "setuid"

and after it:

(/opt/SUNWspro/WS6U2/bin/sparcv9/dbx) print len, n, buf
len = 0
n = 2U
buf = 0x390cb0 "<bad address 0x390cb0>"

It looks like yy_flex_alloc() is returning a bad value - the
address space map of the binary is all above hex 0x100000000:

$m
            BASE            LIMIT             SIZE NAME
       100000000        1001b0000           1b0000 a.out
       1001be000        1001ee000            30000 a.out
       1001ee000        10038a000           19c000 a.out
ffffffff7f600000 ffffffff7f628000            28000 ld.so.1
ffffffff7f726000 ffffffff7f72a000             4000 ld.so.1
ffffffff7fffe000 ffffffff80000000             2000 [ stack ]

I've seen this sort of thing before - Berkeley DB 4.2.52 also
has a problem with being compiled for 64-bit (it gets a similar
bad value back from the 64-bit libnsl.so's svctcp_create()
function, apparently - among other things - because their RPC
stub .x file was run through "rpcgen" in 32-bit mode).

I'm not sure if there's a way to fix this - should I rebuild
"flex" - and, heck, since it's yy_flex_alloc(), maybe "bison" too -
as 64-bit binaries?  Or just give up and build libpcap/tcpdump
as 32-bit binaries instead?

Thanks,

        - Greg

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.