SINIX: Assertion Failure in uxwrap.c

VERIFIED FIXED

Status

NSPR
NSPR
P3
normal
VERIFIED FIXED
20 years ago
3 years ago

People

(Reporter: Wan-Teh Chang, Assigned: Wan-Teh Chang)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

20 years ago
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.

Updated

19 years ago
Component: Macintosh FE

Comment 1

19 years ago
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.
(Assignee)

Comment 2

19 years ago
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.
(Assignee)

Comment 3

19 years ago
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.
(Assignee)

Comment 4

19 years ago
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.
(Assignee)

Comment 5

19 years ago
Marc (fraioli@dg-rtp.dg.com) reported:
    I get the following:

    pd->in_flags == POLLIN
    pd->out_flags == POLLHUP
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 6

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 7

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

Comment 8

19 years ago
NSPR now has its own Bugzilla product.  Moving this bug to the NSPR product.
You need to log in before you can comment on or make changes to this bug.