Last Comment Bug 283 - SINIX: Assertion Failure in uxwrap.c
: SINIX: Assertion Failure in uxwrap.c
Status: VERIFIED FIXED
:
Product: NSPR
Classification: Components
Component: NSPR (show other bugs)
: other
: Other Other
P3 normal (vote)
: ---
Assigned To: Wan-Teh Chang
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 1998-04-29 18:59 PDT by Wan-Teh Chang
Modified: 2014-04-28 20:48 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description User image Wan-Teh Chang 1998-04-29 18:59:54 PDT
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.
Comment 1 User image Marc Fraioli 1998-08-27 07:54:59 PDT
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.
Comment 2 User image Wan-Teh Chang 1998-08-27 08:10:59 PDT
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.
Comment 3 User image Wan-Teh Chang 1998-08-27 08:11:59 PDT
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.
Comment 4 User image Wan-Teh Chang 1998-08-27 08:16:59 PDT
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.
Comment 5 User image Wan-Teh Chang 1998-08-27 16:25:59 PDT
Marc (fraioli@dg-rtp.dg.com) reported:
    I get the following:

    pd->in_flags == POLLIN
    pd->out_flags == POLLHUP
Comment 6 User image Wan-Teh Chang 1998-11-16 15:08:59 PST
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.
Comment 7 User image glynn 1999-02-05 08:04:59 PST
I am going to mark this verified against the old code base.
Comment 8 User image Terry Weissman 1999-04-27 10:59:59 PDT
NSPR now has its own Bugzilla product.  Moving this bug to the NSPR product.

Note You need to log in before you can comment on or make changes to this bug.