58728 - N601 Linux #1 crash on' open web location' dialog [@ nsJARChannel::OnStartRequest]

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[David Hugh-Jones]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdk i686; en-US; m18) Gecko/20001029
BuildID:    2000102906

      when trying to open a web location using ctrl+L or the File menu item
"open web location", Mozilla crashes when enter is pressed or the "Open" button
is pressed.

Reproducible: Always
Steps to Reproduce:
1. File-->open web location ; or Ctrl+L
2. type or paste in a URL
3. hit enter or click "open"

Actual Results:  browser crashes

Expected Results:  open location normally

Comment 1

[Kathleen :Brade]

using a NS6 build from 1031 (1400) on Linux, I can't reproduce this bug.

Comment 2

[Jeffrey Baker]

Doesn't crash on Linux 2000-11-01-06 MTrunk.

Comment 3

[sairuh (rarely reading bugmail)]

actually, i've seen this --but it's annoying to repro-- it seems that it occurs
when i paste from another app [eg, in my case, say, gaim, aim or xchat] into the
Open Web Location.

David, are you running this with a talkback build? if so, when talkback appears,
enter your email address and i'll search for it [the info lands into an internal
server] and enter the stack info in this report. let me know if/when you've done
this --thanks!

Comment 4

[sairuh (rarely reading bugmail)]

hokay, finally got a talkback report (incident #20199074), caused when i pasted
a url that i had typed in an xterm.

Trigger Time             2000-11-01 11:45:20 
 Email Address           [e-mail] 
 User Comments           pasting url into Web Loc [from xterm] 
 Build ID                2000103009 
 Product ID              Netscape6.00 
 Platform ID             LinuxIntel 
 Stack Trace
nsJARChannel::OnStartRequest() 
nsOnStartRequestEvent::HandleEvent() 
nsStreamListenerEvent::HandlePLEvent() 
PL_HandleEvent() 
PL_ProcessPendingEvents() 
nsEventQueueImpl::ProcessPendingEvents() 
event_processor_callback() 
our_gdk_io_invoke() 
libglib-1.2.so.0 + 0xeaca (0x40665aca) 
libglib-1.2.so.0 + 0x10186 (0x40667186) 
libglib-1.2.so.0 + 0x10751 (0x40667751) 
libglib-1.2.so.0 + 0x108f1 (0x406678f1) 
libgtk-1.2.so.0 + 0x8c5b9 (0x4058c5b9) 
nsAppShell::Run() 
nsAppShellService::Run() 
main1() 
main() 
libc.so.6 + 0x189cb (0x4025e9cb) 

Comment 5

[David Hugh-Jones]

It does seem to happen when I cut and paste an address into the dialog, usually by middle clicking in unix fashion.
But I have also reproduced it just by typing an address in and hitting return. Just tried again and it crashed all right.
This is with a recent nightly, so NS6 may be OK.

Comment 6

[sairuh (rarely reading bugmail)]

i can get this using netscape6 [commercial branch 2000.11.06.09-n6]. again, the
annoying aspect is that it doesn't occur every time i paste [middle+click] into
the Open Web Location dialog.

cc'ing akkana, jag and bill --have either of you seen this, or have ideas as to
why it might be occurring?

Comment 7

[Bill Law]

Nope, I haven't seen this.  From the look of the call stack, it appears to be a 
Unix event handling kind of thing.

Comment 8

[sairuh (rarely reading bugmail)]

kin/saari/heikki, have any of you encountered this, or might know what would
cause this crash?

Comment 9

[saari (gone)]

No idea, but CCing pav and damn since it may be event queue releated.

Comment 10

[Dan M]

The stack trace is completely normal data stream processing stuff. I was able to 
reproduce this crash on the 17th attempt. Same stack trace but for the top two 
entries:

nsHTTPServerListener::OnDataAvailable (nsHTTPResponseListener.cpp#451 rev 1.132)
nsOnDataAvailableEvent::HandleEvent 

in my case, it was crashing because the nsHTTPServerListener object's member 
variable mResponseDataListener was null (and it was trying to call 
mResponseDataListener->OnDataAvailable). The rest of the mResponseDataListener 
object looked reasonable, and its mRefCnt = 1. Sound familiar, networking guys?

Comment 11

[Yaron Minsky]

I have experienced this bug as well.  For me, there's been no relation to
cutting and pasting:  it happens unpredictably when I use the "Open Web
Location" dialog, but I always type into it.  It's been present in daily builds
for the last few weeks at least.  It's a rather annoying bug, since I use Ctl-L
a lot to open web pages.  It means the damn thing crashes on my quite a bit.

Comment 12

[Darin Fisher]

added keyword qawanted.

Comment 13

[chris hofmann]

looks like this one at the top of the list for
low memory crashes on linux. lots of hits on 
low memory linux boxes.  here is data from 
some recent talkback analysis

Crash Analysis from Netscape6 RTM candidate build

  nsJARChannel::OnStartRequest
                                    # recent crashes
             0 MB > and <=   32 MB         4
            32 MB > and <=   64 MB         44
            64 MB > and <=  128 MB         28
           128 MB > and <=  256 MB         7
           256 MB > and <=  512 MB         1
           512 MB > and <= 1024 MB         1

maybe the key to reproducability is to try on 
low memory systems, or run for a while to soak
up some memory.

Comment 14

[pohl]

cc to self; see bug 64769, which may be the same thing.  Could somebody point
me to a primer on producing a stack trace from my crash?  Do I have to configure
the build, or run some tool...?

Comment 15

[Darin Fisher]

Try running mozilla from GDB, then you can get a backtrace when moz crashes.

or... if GDB gives you trouble...

Try enabling the ah_crap_handler in mozilla/xpfe/bootstrap/nsSigHandlers.cpp

It will SIGSTOP moz on a crash so you can attach GDB and get a backtrace
that way.

Also, check out http://www.mozilla.org/unix/debugging-faq.html

Comment 16

[Gagan]

This is happening cuz occasionally the abort kicks in while there is still a
onDataAvail event in the queue. Even though this should not be happening, I have
put in a null-check fix to at least avoid the crash. Attaching that...

Comment 17

[Gagan]

Attachment: null check crash fix.

Comment 18

[Darin Fisher]

r=darin on gagan's patch

Comment 19

[Chris McAfee]

.8, get a sr and get this puppy in please!

Comment 20

[Alec Flett]

sr=alecf

Comment 21

[Gagan]

checked in. 

Comment 22

[lchiang]

sairuh - do you still see this bug?
If not sure, we should get jpatel or namachi to do some talkback queries to 
ensure the bug is no longer showing up in talkback reports on more recent trunk 
builds.  thanks.

Comment 23

[sairuh (rarely reading bugmail)]

jay/shiva, could you do some talkback queries to see how frequently this crash
is occurring these days?

i haven't encountered this for some time, so am gonna verify this.

jay/shiva, pls do reopen if your reports show this is still an issue. thx a lot!

Comment 24

[Shiva Thirumazhusai]

This only happens in N601 releases. I don't see them in current Trunk
or M08 builds. 

Shiva

Comment 25

[pohl]

This has been much better in trunk builds, but I have noticed what might
be an edge-case that hasn't been fixed:  if the very first thing that I do 
when I start mozilla is ctrl+L to open a location, it will sometimes
crash on submitting the dialog.  I am not requesting that the bug be reopened,
though.

Comment 26

[Darin Fisher]

pohl: are you seeing the same stack trace when it crashes?

Comment 27

[pohl]

I never did manage to generate a stace trace.  My first
attempts were stopped short by the debian gdb hurdle, and
I became sidetracked by other things. Maybe things aren't
so difficult now.  I'll post one if I succeed.

http://www.mozilla.org/unix/debugging-faq.html#debian

Comment 28

[Darin Fisher]

If it's a different stack trace, then please open a new bug.  But, if it's
the same stack trace, then please let us know.  Thanks!