Created by Wan-Teh Chang (wtc@netscape.com) on Wednesday, April 29, 1998 11:59:54 AM PDT Additional Details : This bug is reported by Sanjay Gupta <gupta@informix.com>. He gets an assertion failure in nsprpub/pr/src/md/unix/uxwrap.c at line 283 PR_ASSERT(nbits > 0); when he runs "mozilla-export -version". The pd->out_flags has the value 0x10 (POLLHUP), meaning that the file descriptor hung up. The stack trace at the assertion failure is: debug> stack Stack Trace for p2, Program (dns [9] 0x180362f4 _kill() [8] 0x1802a658 abort() [7] 0x00a77d40 PR_Assert(s="nbits > 0", file="uxwrap.c", ln=289) [prlog.c@415] [6] 0x00ab3fb8 select(width=1024, rd=0x7ffed860, wr=0x0, ex=0x0, tv=0x0) [uxwrap.c@289] [5] 0x006d00fc dns_driver_main_loop(in_fd=0, out_fd=1) [unix-dns.c@858] [4] 0x006cfbfc dns_driver(argc=1, argv=0x7ffef8a4, in_fd=0, out_fd=1) [unix-dns.c@720] [3] 0x006d064c DNS_SpawnProcess(argc=1, argv=0x7ffef8a4) [unix-dns.c@1021] [2] 0x004f2454 XFE_InitDNS_Early(argc=1, argv=0x7ffef8a4) [xfe-dns.c@58] [1] 0x00489870 main(argc=1, argv=0x7ffef8a4) [mozilla.c@2051] [0] 0x0040ffe4 _start() debug> If he runs without the -version option, it seems that the application forks and the process p1 gets a SIGALRM with the following stack trace: > debug> run SIGNALED 14 (alrm) in p1 [_sigprocmask] 0x18041b94(_sigprocmask+20:) beq a3,zero,0x18041ba8 0x18041b98(_sigprocmask+24:) lw at,-32468(gp) debug> stack Stack Trace for p1, Program mozilla-export [4] 0x18041b94 _sigprocmask() [3] 0x00aab3f8 _MD_UnblockClockInterrupts() [unix.c@2274] [2] 0x00a87c54 PR_UnblockClockInterrupts() [prinit.c@184] [1] 0x0048a7d8 main(argc=1, argv=0x7ffef89c) [mozilla.c@2430] [0] 0x0040ffe4 _start() If he makes p2 runnable, it hangs forever in poll(), the stack trace at that point is debug> set %proc p2 Current process is now p2, program mozilla-export debug> run Process p2 exec'd; new executable is (dns, program (dns HALTED p2 [main in mozilla.c] 2015: <no source text available> debug> run debug> HALTED p2 [_poll] 0x18046534(_poll+20:) beq a3,zero,0x18046554 0x18046538(_poll+24:) li at,91 debug> stack Stack Trace for p2, Program (dns [4] 0x18046534 _poll() [3] 0x00aaa550 _MD_PauseCPU(ticks=4294967295) [unix.c@1854] [2] 0x00a9bbac _PR_CPU_Idle(_cpu=0xd8b000) [prucpu.c@5025504] [1] 0x00aa06d8 _PR_UserRunThread() [pruthr.c@467] [0] 0x00aa06d8 _PR_UserRunThread() [pruthr.c@467] debug> If he runs outside the debugger, it seems to be getting the info from the URL, like it says that contacted, transferring data and so on and suddenly it crashes with the same assertion failure. The output of 'uname' on his machine is: SINIX-Y dagobert 5.43 C2003 RM600 4/512 R10000 He is building with the native cc and CC.

FWIW, I get this same behavior on DG/UX (uname -a output:dgux sac1 R4.20MU02 generic AViiON PentiumPro). I also note that when I leave Mozilla via File->Exit, I get the same assertion failure. Whenever I hit this assertion failure, I also get a core dump. I'll rebuild debuggable so I can get a useful stack trace out of it.

Added gupta@informix.com and fraioli@dg-rtp.dg.com to the Cc list. Accepted the bug. I had a fix/workaround for this bug before but forgot to check it in. The fix/workaround is to have the select() function report the fd with the POLLHUP event as readable. Now I need to ask both of you a favor: please reproduce this problem and tell me the values of pd->in_flags and pd->out_flags at the assertion failure. We already know that pd->out_flags is POLLHUP, but we forgot to look at pd->in_flags last time. Thanks.

Accepted the bug. I had a fix/workaround for this bug before but forgot to check it in. The fix/workaround is to have the select() function report the fd with the POLLHUP event as readable. Now I need to ask you a favor: please reproduce this problem and tell me the values of pd->in_flags and pd->out_flags at the assertion failure. We already know that pd->out_flags is POLLHUP, but we forgot to look at pd->in_flags last time. Thanks.

Accepted the bug. I had a fix/workaround for this bug before but forgot to check it in. The fix/workaround is to have the select() function report the fd with the POLLHUP event as readable. Now I need to ask you a favor: please reproduce this problem and tell me the values of pd->in_flags and pd->out_flags at the assertion failure. We already know that pd->out_flags is POLLHUP, but we forgot to look at pd->in_flags last time. Thanks.

Marc (fraioli@dg-rtp.dg.com) reported: I get the following: pd->in_flags == POLLIN pd->out_flags == POLLHUP

This bug has been fixed. /cvsroot/mozilla/nsprpub/pr/src/md/unix/uxwrap.c, revision 3.5. When we get the POLLHUP event, we mark the fd readable.

I am going to mark this verified against the old code base.

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/d5f55caf5e6e8b3fabd7c148509ccc72294281d6 Fix issue #283, add dns-prefetch, preconnect for editor iframe https://github.com/mozilla/kuma/commit/f34f7da2f5b4bb1e811499b8c0d40960898e8ec3 Merge pull request #4455 from schalkneethling/issue#283-editor-performance-prefetch-preconnect Fix issue #283, add dns-prefetch, preconnect for editor iframe