HP-UX crash on inject while receiving

["Harley Stenzel" <hstenzel () gmail com>]

Greetings--

I'm seeing something quite strange.

I have a libpcap stack application.  One thread may send while another
thread both receives and sends.  (Sends in response to a packet, and
send in response to a timeout).

This works fine on Solaris, which also uses DLPI.

On HP-UX, transmission from the receiver thread works properly, but
inject from the timer thread causes libpcap to core.

So, that leaves me with 3 questions:

1) Is this something that should generally be expected to work?
2) If I wrote up a minimal testcase, would that be helpful in getting
this fixed?
3) Or, should I architect my application around this limitation (in
which case, I suggest it should be documented)

I'm on libpcap 0.9.4 (+inject rc patch), HP-UX 11.23 on ia64

Thanks.

--Harley

gdb excerpts follow:

Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object
#0  pcap_inject_dlpi (p=0x6000000000013650, buf=0x9fffffffef720890)
   at ./pcap-dlpi.c:1503
1503            dlp->dl_primitive = DL_HP_RAWDATA_REQ;
(gdb) bt
#0  pcap_inject_dlpi (p=0x6000000000013650, buf=0x9fffffffef720890)
   at ./pcap-dlpi.c:1503
#1  0xc0000000028f6c90:0 in pcap_inject (p=0x6000000000013650,
   buf=0x9fffffffef720890, size=60) at ./pcap.c:782
#2  0x4000000000016eb0:0 in os_packetxmit
. . .

# look at call into pcap_inject
(gdb) frame 1
#1  0xc0000000028f6c90:0 in pcap_inject (p=0x6000000000013650,
   buf=0x9fffffffef720890, size=60) at ./pcap.c:782
782             return (p->inject_op(p, buf, size));

# look at args.  This is sending an arp, padded to hardware min size
$7 = (struct pcap *) 0x6000000000013650
(gdb) print size
$8 = 60
(gdb) x/60xb buf
0x9fffffffef720890:     0xff    0xff    0xff    0xff    0xff    0xff
0x00    0x30
0x9fffffffef720898:     0x6e    0xf4    0x5a    0x31    0x08    0x06
0x00    0x01
0x9fffffffef7208a0:     0x08    0x00    0x06    0x04    0x00    0x01
0x00    0x30
0x9fffffffef7208a8:     0x6e    0xf4    0x5a    0x31    0x0a    0x2a
0x72    0xd3
0x9fffffffef7208b0:     0x00    0x00    0x00    0x00    0x00    0x00
0x0a    0x2a
0x9fffffffef7208b8:     0x72    0xd6    0x00    0x00    0x00    0x00
0x00    0x00
0x9fffffffef7208c0:     0x00    0x00    0x00    0x00    0x00    0x00
0x00    0x00
0x9fffffffef7208c8:     0x00    0x00    0x00    0x00

# look at the pcap_t passed in:
(gdb) print *p
$9 = {
 fd = 3,
 selectable_fd = 3,
 send_fd = 4,
 snapshot = 4096,
 linktype = 1,
 tzoff = 0,
 offset = 2,
 break_loop = 0,
 }
. . . there's more, but it looks good.
(gdb)

Show that this happens when 2 threads use pcap_t at the same time:

(gdb) info thread
*   4 system thread 1190830    0xc0000000028f6c90:0 in pcap_inject (
   p=0x6000000000013650, buf=0x9fffffffef720890, size=60) at ./pcap.c:782
   3 system thread 1190829    0xc000000000321c10:0 in __sigtimedwait_sys
  +0x30 () from /lib/hpux64/libc.so.1
   2 system thread 1190828    0xc00000000031b5f0:0 in _getmsg_sys+0x30 ()
  from /lib/hpux64/libc.so.1
   1 system thread 1190827    0xc0000000001187b0:0 in ___lwp_wait_sys+0x30 ()
  from /lib/hpux64/libpthread.so.1

(gdb) thread 2
[Switching to thread 2 (system thread 1190828)]
#0  0xc00000000031b5f0:0 in _getmsg_sys+0x30 () from /lib/hpux64/libc.so.1
(gdb) bt
#0  0xc00000000031b5f0:0 in _getmsg_sys+0x30 () from /lib/hpux64/libc.so.1
#1  0xc00000000032bcb0:0 in getmsg ()
   at ../../../../../core/libs/libc/shared_em_64/../core/syscalls/t_getmsg.c:21
#2  0xc0000000028f1380:0 in pcap_read_dlpi (p=0x6000000000013650, cnt=1,
   callback=0x9fffffffef7db008, user=0x6000000000013650 "")
   at ./pcap-dlpi.c:284
#3  0xc0000000028f58d0:0 in pcap_loop () at ./pcap.c:107
#4  0x400000000000e6d0:0 in hpux_recv_pthread (pcapt=0x6000000000013650)
   at hp_entry.c:112
#5  0xc0000000000b6c00:0 in __pthread_bound_body ()
   at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4511

# Show that another thread is listening on the same pcap_t

(gdb) frame 4
#4  0x400000000000e6d0:0 in hpux_recv_pthread (pcapt=0x6000000000013650)
   at hp_entry.c:112
112         rc = pcap_loop(pcapt, 1, hpux_pcaphandler, (void *)pcapt);
(gdb) bt
#0  0xc00000000031b5f0:0 in _getmsg_sys+0x30 () from /lib/hpux64/libc.so.1
#1  0xc00000000032bcb0:0 in getmsg ()
   at ../../../../../core/libs/libc/shared_em_64/../core/syscalls/t_getmsg.c:21
#2  0xc0000000028f1380:0 in pcap_read_dlpi (p=0x6000000000013650, cnt=1,
   callback=0x9fffffffef7db008, user=0x6000000000013650 "")
   at ./pcap-dlpi.c:284
#3  0xc0000000028f58d0:0 in pcap_loop () at ./pcap.c:107
#4  0x400000000000e6d0:0 in hpux_recv_pthread (pcapt=0x6000000000013650)
   at hp_entry.c:112
#5  0xc0000000000b6c00:0 in __pthread_bound_body ()
   at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4511
(gdb) list
112         rc = pcap_loop(pcapt, 1, hpux_pcaphandler, (void *)pcapt);
(gdb) print pcapt
$12 = (struct pcap *) 0x6000000000013650
(gdb) print *pcapt
$13 = {
 fd = 3,
 selectable_fd = 3,
 send_fd = 4,
 snapshot = 4096,
 linktype = 1,
 tzoff = 0,
 offset = 2,
 break_loop = 0,
 sf = {
   rfile = 0x0,
   swapped = 0,
   hdrsize = 0,
   lengths_swapped = NOT_SWAPPED,
   version_major = 0,
   version_minor = 0,
   base = 0x0
 },
. . .

Note that $12 == $7, so the pcap_t is the same.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.