4225 - NECKO: [PP]Timer: crash closing main viewer window while opening new window

Status: RESOLVED FIXED

(Core Graveyard :: Viewer App, defect, P3)

Description

[Dan M]

On a fresh pull from late 23 Mar 99 these steps seem to reliably crash:

launch viewer
open a new window
while the new window is spinning up (writing to the console window),
  hit the "close" widget on the first window
app continues until the second window has loaded, then crashes

I'm seeing this on Linux but not Windows.  Can't try it on Mac -- at the
moment, my Mac build won't even launch.  But that's another bug.

Stack trace says the crash is happening in the EndLoadURL methods,
as nsWebCrawler is trying to get its presentation shell using deleted
member variables.  Sounds like a fun one.

Comment 1

[rickg]

Ramiro -- please take a look.

Comment 2

[ramiro]

tried apr 6 build, both nt and linux.  problem occurs only on linux.

here is what i did:

1. launch viewer
2. File->New Window
3. Load www.freshmeat.net on first window
4. Close 2nd window while first window is spiining

BOOM!

consistently crashes with this stack trace:

#0  0x40ba86a1 in __kill ()
(gdb) where
#0  0x40ba86a1 in __kill ()
#1  0x40ba84cf in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x40ba96df in abort () at ../sysdeps/generic/abort.c:83
#3  0x408ba01c in PR_Assert (s=0x406b5e34 "0", file=0x406b5e29 "mkgeturl.c",
ln=3283) at prlog.c:480
#4  0x406a0d4e in NET_ProcessNet (ready_fd=0x0, fd_type=2) at mkgeturl.c:3283
#5  0x406a8d11 in NET_PollSockets () at mkselect.c:298
#6  0x40678b46 in nsNetlibService::NetPollSocketsCallback (aTimer=0x8224798,
aClosure=0x80f52e8) at nsNetService.cpp:1277
#7  0x404f7de9 in TimerImpl::FireTimeout (this=0x8224798) at nsTimer.cpp:73
#8  0x404f82d2 in nsTimerExpired (aCallData=0x8224798) at nsTimer.cpp:189
#9  0x40a579dc in g_timeout_dispatch (source_data=0x82274b0,
current_time=0xbfffeff8, user_data=0x8224798) at gmain.c:1214
#10 0x40a56cb3 in g_main_dispatch (current_time=0xbfffeff8) at gmain.c:656
#11 0x40a5723b in g_main_iterate (block=1, dispatch=1) at gmain.c:865
#12 0x40a573bd in g_main_run (loop=0x815af08) at gmain.c:923
#13 0x40983d9f in gtk_main () at gtkmain.c:475
#14 0x4004ada8 in nsAppShell::Run (this=0x80748a8) at nsAppShell.cpp:208
#15 0x80532b2 in nsNativeViewerApp::Run (this=0x806ee48) at nsGTKMain.cpp:42
#16 0x80534c6 in main (argc=1, argv=0xbffff0a4) at nsGTKMain.cpp:97

looks like a timer bug.

marking assigned m5.

adding Timer: to summary

Comment 3

[Bruce Mitchener]

Possibly related to bug #4127?

Comment 4

[Chris McAfee]

I'll take a look at this for M5.

Comment 5

[chris hofmann]

mcafee, any ideas on this one?

Comment 6

[Chris McAfee]

M6 per chofmann's advice.

Comment 7

[Chris McAfee]

Adding netlib help to CC line.
I find this crashing all over netlib, sometimes in mkgeturl.c, sometimes
in mkhttp.c.  On Unix, netlib lives in the UI thread, any ideas, netlib people?

Comment 8

[Chris McAfee]

*** Bug 5895 has been marked as a duplicate of this bug. ***

Comment 9

[Chris McAfee]

*** Bug 6070 has been marked as a duplicate of this bug. ***

Comment 10

[Chris McAfee]

Gagan, this is the netlib/timer problem.
This must be a dup of a bug on your list,
can you take a look?  Please add me to the CC list
of the real bug number.

Comment 11

[chris hofmann]

unlikely to be resolved until after necko lands. -> m7

Comment 12

[James Everingham]

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or
early M9.  We will need to get on this and it cannot be postponed past the M9
milestone.

Comment 13

[Gagan]

Pl. verify with Necko.

Comment 14

[leger]

Adding crash keyword