Closed Bug 283 Opened 26 years ago Closed 7 years ago

SINIX: Assertion Failure in uxwrap.c

Categories

(NSPR :: NSPR, defect, P3)

Other
Other
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wtc, Assigned: wtc)

Details

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.
Component: Macintosh FE
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
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
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
Status: VERIFIED → RESOLVED
Closed: 26 years ago7 years ago
You need to log in before you can comment on or make changes to this bug.