[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Support #TXN-293177]: LDM 6.6.5: make failure on Intel Mac (OS X 10.5)

Dave,

I managed to get the following stack dump of the hung downstream
LDM process on Virga that was receiving IDS data from us:

(gdb) where
#0  0x957587c1 in fcntl$UNIX2003 ()
#1  0x00028a76 in fd_lock (fd=1, cmd=9, l_type=3, offset=0, l_whence=0, 
extent=4096) at pq.c:3106
#2  0x00028d91 in rgn_lock (pq=0x101670, offset=0, extent=4096, rflags=4) at 
pq.c:3312
#3  0x0002994b in mm0_ftom (pq=0x101670, offset=0, extent=4096, rflags=4, 
ptrp=0x10168c) at pq.c:3785
#4  0x0002a99d in ctl_get (pq=0x101670, rflags=4) at pq.c:4361
#5  0x0002bad3 in pqe_new (pq=0x101670, infop=0x1220c0, ptrp=0x349a8, 
indexp=0xbfffe42c) at pq.c:5078
#6  0x00007fcf in down6_comingsoon (argp=0xbfffe4b0) at down6.c:355
#7  0x0000ace5 in comingsoon_6_svc (comingPar=0xbfffe4b0, rqstp=0xbfffe9dc) at 
ldm6_server.c:678
#8  0x0000b008 in ldmprog_6 (rqstp=0xbfffe9dc, transp=0x100530) at 
ldm6_svc.c:128
#9  0x0001515f in svc_getreqsock (sock=4) at svc.c:543
#10 0x00022696 in one_svc_run (xp_sock=4, inactive_timeo=60) at one_svc_run.c:89
#11 0x0000d60f in run_service (socket=4, inactiveTimeout=60, upName=0x101470 
"idd.unidata.ucar.edu", upAddr=0xbfffec34, upId=19781, pqPathname=0xbfffefb7 
"/usr/local/unidata/ldm/prodqueue/ldm.pq", expect=0x101490, pq=0x101670) at 
requester6.c:228
#12 0x0000e317 in req6_new (upName=0x101470 "idd.unidata.ucar.edu", port=388, 
request=0x101890, inactiveTimeout=60, pqPathname=0xbfffefb7 
"/usr/local/unidata/ldm/prodqueue/ldm.pq", pq=0x101670, isPrimary=0) at 
requester6.c:671
#13 0x000036ce in prog_requester (source=0x101470 "idd.unidata.ucar.edu", 
port=388, clssp=0x101890, isPrimary=0, hostCount=2) at acl.c:1508
#14 0x00003beb in run_requester (hostId=0x101470 "idd.unidata.ucar.edu", 
port=388, clssp=0x101890, isPrimary=0, hostCount=2) at acl.c:1680
#15 0x00003ccd in new_requester (remoteLocation=0x100428, clssp=0x101890, 
isPrimary=0, hostCount=2) at acl.c:1735
#16 0x00003d29 in requester_add (remoteLocation=0x100428, clssp=0x101890, 
isPrimary=0, hostCount=2) at acl.c:1779
#17 0x00003ecf in invert_request_acl (ldmPort=388) at acl.c:1844
#18 0x00007819 in read_conf (conf_path=0xbfffefdf 
"/usr/local/unidata/ldm/etc/ldmd.conf", doSomething=1, defaultPort=388) at 
parser.y:635
#19 0x0000c964 in main (ac=6, av=0xbfffeeac) at ldmd.c:1012

Mike Schmidt tried to get a "dtruss" dump of the system calls that
process was making but nothing was printed.  He was able to get
"dtruss" output for the downstream LDM that was receiving IDS data
from Washington.

Both of the above are consistent with a bug in the operating
system that's preventing the fcntl() system-call from returning
-- they're also consistent with what we've been seeing up to now.

Mike is going to look into getting access to an Apple bug-reporting
site to see if anyone else has reported this problem.

Sorry for the bad news.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: TXN-293177
Department: Support LDM
Priority: Normal
Status: Open