Closed Bug 243522 Opened 20 years ago Closed 19 years ago

crash/hang (dereferencing null pointer) when using ctrl-shift-tab [@ nsEventStateManager::GetPrevDocShell ]

Categories

(Firefox :: Tabbed Browser, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

()

VERIFIED DUPLICATE of bug 162283

People

(Reporter: ifreecarve, Unassigned)

References

Details

(Keywords: crash, hang)

Crash Data

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

get an error that firefox tried to read memory at 0x000000....  this ALWAYS
happens when i am using ctrl-shift-tab, USUALLY when there are enough tabs open
that the "selected" tab is not displayed on the tab bar (due to the tabs
reaching their minimum width and pushing the rest out of view).

Reproducible: Sometimes
Steps to Reproduce:
1. open a lot of tabs, so that they reach their minimum width.  
2. ctrl-tab to a tab that is not visible (one on the "far right")
3. run a search on google, ebay, wherever... (get a page of links)
4. open 10 or so links from that page in new tabs
5. ctrl-tab over all of your new tabs until you "wrap around" to the tab on the
far left of the bar
6. ctrl-shift-tab back to your page of links - the browser should crash before
it gets all the way back.

Actual Results:  
didnt try it, i dont want to crash this bug report! (sorry)

Expected Results:  
the browser NOT crashing

module firefox.exe i believe.  something like "tried to access memory at
location 0x000000, the memory could not be 'read' "....
I can confirm this.
I happens with release FireFox 0.8 on Windows 2000 SP4
I'm on dialup, so that may be a factor.
What I do is go to a page like :
  http://www.wallpapers.cz/animals1.html
and middle-click all the images to open the in a new tab in the background
than I ctrl+tab ctrl+shift+tab between the jpegs until it crashes
(a matter of seconds)

with the latest nightly trunk (as of today ) 
    Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040516
Firefox/0.8.0+

instead of the crash I get a hang ( firefox eats up all the cpu)
You should note that this Control-Shift-Tab (Ctrl-Shift-Tab) incuded bug is also
reported over at http://bugzilla.mozilla.org/show_bug.cgi?id=236891
I have seen this for a while now (atleast 0.8 thru to 0.9 testing candidate) and
it is the one and only important visible bug I know of in Firefox yet it alone
makes me perceive Firefox as fairly unstable

I atleast know it happens when a fair number of tabs are open and I 
ctrl+shift+tab from one back to another. From what I've seen tabs haven't had to
"wrap around" for it to happen. and I have never had an error dialog, it just
hangs. fairly reproducable and it may even be reproducable every time I just
haven't tested enough to know

bug 236891 appears to not be related to this bug as that is about "getting back
from another app" where-as this bug is about moving about within the same app
Status: UNCONFIRMED → NEW
Ever confirmed: true
> bug 236891 appears to not be related to this bug as that is about "getting back
> from another app" where-as this bug is about moving about within the same app
> 

Actually it is directly related.
Both happen upon a ctrl+shift+tab
The hang is more easily reproducible, while the crash  isn't.
I've had this bug a *lot* of times...

Open around 5 or 6 tabs. Go to the rightmost one. Click some link so that the
rotating arrows come on the tab... (Page loading). Now press Ctrl+****+Tab. 60%
hang rate :-(

Nandz.
I can confirm this bug, and I think I know what's causing it now (been trying to
figure out for several months because it keeps happening to me)

Steps to reproduce:
1) Load a page such as http://forums.mozillazine.org
2) Open at least 2 new tabs such as middle clicking Firefox General and Firefox
Builds
3) Close the current tab fast enough so that the first new tab (Firefox General)
is still loading => The Firefox General tab gains focus from the finished
loading tab (http://forums.mozillazine.org)
4) Ctrl-shift-tab to the now second tab (Firefox Builds) => Firefox crashes

I think it has something to do with not being able to ctrl-tab/ctrl-shift-tab
loading tabs (which is kinda annoying). But since the loading tab (Firefox
General) gained focus from a completed tab (http://forums.mozillazine.org), some
variable probably isn't set correctly to prevent the user from ctrl-shift-tabbing.
Just for a better example than the mozillazine forums (it's no longer under
heavy stress conditions so the pages load faster now).

Go to http://agadak.net/10sec.php, and it should take 3 seconds to load.
Load a couple more tabs using the link there (it goes to itself), and those
pages should take at least 10 seconds to load.
Close the current tab and gain focus to the newly opened tab that is still
loading then ctrl-shift-tab to crash.

Always hangs for me, but according to ian, there was a null pointer error ->
crash.. ? Keyword: + crash, hang ?
Flags: blocking1.0?
Just to make sure it wasn't some extension/theme/external problem, I made a new
profile for Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040614 Firefox/0.9 and crashes using my example of
http://agadak.net/10sec.php.
I looked around /mozilla/xpfe/global/resources/content/bindings/tabbox.xml and
noticed that both ctrl-(shift)-tab called the same functions as
ctrl-page-up/down, so I tried to crash it using ctrl-page-up, but it didn't
freeze as expected. So because it doesn't crash with ctrl-pg-up and with
ctrl-shift-tab, it might be something else that is catching the ctrl-shift-tab
event causing the problem. Oh yeah.. there are some null pointer exceptions
thrown in tabbox.xml that seem to go with the dereferencing null pointer issue,
but I haven't been able to test things.. the code doesnt want to compile for me.

Also some other things.. Firefox still crashes even if there are
non-still-loading tabs before the tab that is closed and/or after the last
loading tab. Meaning that you could open a couple tabs that take some time to
load and then another one that loads quickly, it will still crash. So doesn't
seem to be a problem of being able to find a correct tab to select (not an
infinite loop)

Anyone else think this should be 1.0 worthy? I suppose it's not that big of a
problem for me anymore now that I know how to trigger the crash.. so I just
avoid doing that :p
Flags: blocking-aviary1.0?
Could anybody provide TalkBack incident ID of this crash with 0.9 nightbuild or
with 0.9.x release?
Keywords: crash
I remember sending in a talkback report, but I don't have the ID... And I can't
get it to catch the crash (freeze) either. Mmm the time I did get the report it
did have the null pointer problem, but the method that I use to freeze the
application always works but never causes a talkback report to trigger. I'll
look through talkback tomorrow when I'm on that computer.
Well, it seems like the talkback entry was wiped when I clean installed 0.9.1.
Also perhaps the method I've been talking about to recreate the bug is actually
causing a different problem. The way I reproduce the bug causes a hang/freeze;
while the one time I got a crash from ctrl-shift-tabbing, there was a
dereference null pointer error and a talkback report. So there might be separate
bugs here...

Anyone know how to search the talkback reports on mozilla.org for something you
send in.. maybe by email address? The other searches such as comments didn't
work for me.
Edward Lee: It's not possible to search e-mail address for privacy reasons. Just
provide TalkBack incident ID of your actual crashes - go to your Firefox
directory, to components/, there start talkback.exe, it'll give you a list with
the IDs.
Yup, I know about the talkback.exe program, and I mentioned that the data wasn't
there anymore probably because I deleted the Mozilla Firefox directory before
upgrading to 0.9.1.

Perhaps the reporter ian has a talkback ID.
I would like to notice that for me this bug always worked as hang, not crash.
Keywords: hang
Summary: crash (dereferencing null pointer) when using ctrl-shift-tab → crash/hang (dereferencing null pointer) when using ctrl-shift-tab
ian here; sorry, i dont think i have a talkback id :(.  it's interesting that
this bug has been switched to crash/hang; i've only gotten crashes under windows
2000, but i recall that under linux (firefox 0.8), ctrl-shift-tab would cause
hangs.  i'm not sure if this is helpful/relevant, but if you run 'top' during
one of these hangs then you should see one of the firefox processes slowly
eating up memory (over the course of a few hours).  has anyone else noticed this?
WinXP SP1, Firefox 0.9.1 with agadak.net example mentioned here - hang, to be
more precize.
Ok, I just got it to crash (accidentally). All of the tabs were done loading and
I was just alt-tabbing back to Firefox and ctrl-shift-tabbing to the previous tab.

Talkback ID: TB317416W
TB317416W:
nsEventStateManager::GetPrevDocShell 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 5319]
nsEventStateManager::ShiftFocusByDoc 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 5369]
nsEventStateManager::PostHandleEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2069]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6088]
PresShell::HandleEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5929]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2239]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2025]
HandleEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 79]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1067]
nsWindow::DispatchKeyEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 2978]
nsWindow::OnKeyDown 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 3068]
Summary: crash/hang (dereferencing null pointer) when using ctrl-shift-tab → crash/hang (dereferencing null pointer) when using ctrl-shift-tab [@ nsEventStateManager::GetPrevDocShell ]
*** Bug 255909 has been marked as a duplicate of this bug. ***
from bug 255909, here are other talkback ids:

TB579127H, TB535971W, TB531217Y

i'm using XP and it happens to me so this shouldn't be just OS win2k.
*** Bug 257932 has been marked as a duplicate of this bug. ***
*** Bug 261981 has been marked as a duplicate of this bug. ***
Works for me with FF 0.10.1
I can confirm hang with 0.10, cpu goes to 50% and stays there.
good news... i can't reproduce this crash anymore on win2k, ever since using
this version:
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
I can confirm that I canNOT reproduce the hang with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041027
Firefox/0.9.1

(why there is still 0.9.1 as version i do not know, is nightly build)
neither could i reproduce it with RC1

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026
Firefox/0.9.1+ 
This is STILL occuring on 1.0RC2, on an XP system.
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103
Firefox/1.0RC2)

Requesting ? on blocking 1.0. I'd consider this a serious problem that needs to
be sorted before launch...
Flags: blocking-aviary1.0?
too late for a non-top crasher without a fix in hand.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
I've started getting something very similar with post-1.0 trunk builds.  It
happens almost every time I'm writing an email on gmail.com and switching back
and forth between tabs.  Talkback incident 3710025.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050127 Firefox/1.0+
Version: unspecified → Trunk

*** This bug has been marked as a duplicate of 162283 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Assignee: bugs → nobody
Status: RESOLVED → VERIFIED
QA Contact: tabbed.browser
Crash Signature: [@ nsEventStateManager::GetPrevDocShell ]
You need to log in before you can comment on or make changes to this bug.