22939 - crash loading fhda.edu

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect, P3)

Description

[Akkana Peck]

Attempting to load fhda.edu leads to a 100% reproducible crash.  Loading
www.fhda.edu works fine.

The stack trace for the crash isn't always the same.  Here is one:

#0  0x40350f72 in __libc_send ()
#1  0x40211671 in send (fd=13, buf=0x4043e200,
n=91, flags=0)
    at wrapsyscall.c:173
#2  0x401efa1b in pt_Send (fd=0x8298f98,
buf=0x4043e200, amount=91, flags=0,
    timeout=4294967295) at ptio.c:1975
#3
0x401efb5d in pt_SocketWrite (fd=0x8298f98, buf=0x4043e200, amount=91)
    at
ptio.c:2026
#4  0x401cdde7 in PR_Write (fd=0x8298f98, buf=0x4043e200, amount=91)
    at priometh.c:125
#5  0x40416a08 in nsWriteToSocket (closure=0x8298f98,

fromRawSegment=0x4043e200 "GET / HTTP/1.0\r\nhost: fhda.edu\r\nuser-agent:
Mozilla/5.0 [en-US] (Linux; I)\r\naccept: */*\r\n\r\n", toOffset=0, count=91,

  writeCount=0xbf5ffc04) at nsSocketTransport.cpp:858
#6  0x4041720e in
nsSocketTransport::doWriteFromStream (this=0x8545888,
    aCount=0xbf5ffc04) at
nsSocketTransport.cpp:1134
#7  0x40416eba in nsSocketTransport::doWrite
(this=0x8545888, aSelectFlags=0)
    at nsSocketTransport.cpp:1016
#8
0x40416166 in nsSocketTransport::Process (this=0x8545888, aSelectFlags=0)
    at
nsSocketTransport.cpp:521
#9  0x40419e07 in nsSocketTransportService::Run
(this=0x83b3508)
    at nsSocketTransportService.cpp:455
#10 0x40171025 in
nsThread::Main (arg=0x85070d8) at nsThread.cpp:83
#11 0x401f392b in _pt_root
(arg=0x852c470) at ptthread.c:157
#12 0x4020dce9 in pthread_start_thread
(arg=0xbf5ffe7c) at manager.c:204

and here is another:
#0  0x40350f72 in __libc_send ()
#1  0x40211671 in send (fd=18, buf=0x40605200,
n=91, flags=0)
    at wrapsyscall.c:173
#2  0x401efa1b in pt_Send (fd=0x855d548,
buf=0x40605200, amount=91, flags=0,
    timeout=4294967295) at ptio.c:1975
#3
0x401efb5d in pt_SocketWrite (fd=0x855d548, buf=0x40605200, amount=91)
    at
ptio.c:2026
#4  0x401cdde7 in PR_Write (fd=0x855d548, buf=0x40605200, amount=91)
    at priometh.c:125
#5  0x405dda08 in g_ufMappingTable ()
#6  0x405de20e in
g_ufShiftTable ()
#7  0x405ddeba in g_ufMappingTable ()
#8  0x405dd166 in
g_T61MappingTable ()
#9  0x405e0e07 in iid.16 ()
#10 0x40171025 in
nsThread::Main (arg=0x8551880) at nsThread.cpp:83
#11 0x401f392b in _pt_root
(arg=0x84ed940) at ptthread.c:157
#12 0x4020dce9 in pthread_start_thread
(arg=0xbf5ffe7c) at manager.c:204

This only kills one thread; continuing past it in gdb, or dismissing the
fullcircle dialog in the optimized build, leaves the browser window still
apparently functional.

Comment 1

[Warren Harris]

Sounds like an nspr problem.

Comment 2

[Wan-Teh Chang]

This crashes in send:__libc_send.  It looks like a
libc problem.  I will take a look at it because
I recently changed PR_Write for sockets to call send
instead of write on Unix.

Comment 3

[Wan-Teh Chang]

I pulled the current tip and did a debug build
on coffee.mcom.com (a Red Hat Linux 6.0 box).
Then I ran it within gdb as follows:
    % cd /builds/wtc/mozilla/dist/bin
    % ./mozilla -g -d gdb

When I entered the URL "fhda.edu", the
process did not crash.  Rather, it received
the SIGPIPE signal, which interrupted gdb.
The stack trace was the same as the first one
you listed.

It is normal to receive SIGPIPE when you
write to a socket whose peer has closed the
connection.  By default, gdb gets interrupted
when it receives a signal. This is not a crash.
There should be a gdb command to make it ignore
a specific signal.

Comment 4

[Akkana Peck]

If you do this in the optimized commercial builds, you get a fullcircle dialog.
That's how I first saw it.  I don't think it's considered acceptable to have
fullcircle dialogs coming up just because the user typed certain urls, is it?

Comment 5

[Wan-Teh Chang]

It is the operating system (Unix/Linux), not NSPR,
that sends the SIGPIPE signal when a process writes
to a broken pipe or socket connection.  Moreover, it
is impossible to avoid writing to a broken socket
connection because you cannot control the peer.  Every
Unix network application must handle (usually ignore)
the SIGPIPE signal. NSPR does this for you.

I cannot own this bug because this is not an NSPR
issue.  Fullcircle needs to be instructed to not
pop up a dialog when the expected SIGPIPE signal is
received.

Comment 6

[Akkana Peck]

Back to netlib.

Comment 7

[Warren Harris]

This is not a netlib bug. The front-end needs to provide a signal handler for
this and not call full circle.

Comment 8

[Akkana Peck]

I'm not at all clear on why we can't just ignore the sigpipe so it doesn't show
up and get caught by other apps like gdb and fullcircle.  We're obviously not
catching it to do anything useful with it.  But whatever.

Leaf says namachi is
the contact for fullcircle stuff.

Comment 9

[leger]

Clearing DUPLICATE resolution due to reopen.  adding namachi to cc list.

Comment 10

[Shiva Thirumazhusai]

Fullcircle is a component in Seamonkey. If you want to debug without fullcircle
please remove the component and try.

Adding cyeh and chofmann in the cc list

Comment 11

[Akkana Peck]

Assigning to namachi (I thought I did that before, but it didn't get through
somehow).

Comment 12

[Wan-Teh Chang]

During NSPR initialization, NSPR installs the
signal action SIG_IGN for SIGPIPE (i.e., ignores
SIGPIPE).  Note that even if a process ignores
or handles a signal, the signal can still be
intercepted by gdb.  I suspect that fullcircle
works the same way and you need to explicitly
tell fullcircle to ignore (not in the sense of
SIG_IGN) the signal.

Comment 13

[Shiva Thirumazhusai]

Following is the reply I got from fullcircle.

When FCInitialize() is called, handlers are registered for most of
the signals, including SIGPIPE.  If you want SIGPIPE or any other
signal to be left alone, you'll need to make whatever changes are
necessary in the disposition of signal handling after the call to
FCInitialize().

Comment 14

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 15

[Blake Ross]

akk is no longer crashing there and neither am i (linux 60208). marking wfm.

Comment 16

[Tom Everingham]

verified WORKSFORME
Linux 2000070420