Closed Bug 184833 Opened 22 years ago Closed 21 years ago

OS/2 - abend on X (close) tab & remove focus

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mrmazda, Assigned: jag+mozilla)

Details

2002121012 OS/2 trunk, but not new

To reproduce:
1-Open 2.02 mail windowed
2-Open Mozilla browser windowed
3-Open pages in more than 4 tabs
4-Make rightmost tab active
5-Click on close tab X
6-Click anywhere in 2.02 window (e.g. - get mail button)

Actual behavior:
1-abend, or not

Expected behavior:
1-Nothing

Notes: This is not reproducable at will, but all four of the following traps
followed this scenario (in 3-4 different builds). This behavior is much older
than 8 Dec, more than a week at least. If I can figure out any particular URL's
to have loaded in tab to be closed I will add as/when found.

12-08-2002  14:53:17  SYS3175  PID 003d  TID 0001  Slot 0070
H:\MOZILLA\BIN\MOZILLA.EXE
c0000005
00000008
P1=00000001  P2=00000008  P3=XXXXXXXX  P4=XXXXXXXX  
EAX=02476503  EBX=01f546bc  ECX=02476ad0  EDX=00000000
ESI=00000000  EDI=00131850  
DS=0053  DSACC=f0f3  DSLIM=ffffffff  
ES=0053  ESACC=f0f3  ESLIM=ffffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:00000008  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0013182c  SSACC=f0f3  SSLIM=ffffffff
EBP=001318c0  FLG=00012206

------------------------------------------------------------

12-09-2002  00:05:05  SYS3175  PID 006f  TID 0001  Slot 0076
H:\MOZILLA\BIN\MOZILLA.EXE
c0000005
01f12f05
P1=00000002  P2=00000000  P3=XXXXXXXX  P4=XXXXXXXX  
EAX=03c017ac  EBX=01a2551c  ECX=01f05aa0  EDX=00000000
ESI=00000000  EDI=00131850  
DS=0053  DSACC=f0f3  DSLIM=ffffffff  
ES=0053  ESACC=f0f3  ESLIM=ffffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:01f12f05  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0013182c  SSACC=f0f3  SSLIM=ffffffff
EBP=001318c0  FLG=00012206

MOZRMI36.DLL

------------------------------------------------------------

12-10-2002  09:35:29  SYS3175  PID 00c6  TID 0001  Slot 0070
H:\MOZILLA\BIN\MOZILLA.EXE
c0000005
00000000
P1=00000001  P2=00000000  P3=XXXXXXXX  P4=XXXXXXXX  
EAX=03ac9050  EBX=013b95ec  ECX=03ac9f50  EDX=00000000
ESI=00000000  EDI=00131850  
DS=0053  DSACC=f0f3  DSLIM=ffffffff  
ES=0053  ESACC=f0f3  ESLIM=ffffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:00000000  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0013182c  SSACC=f0f3  SSLIM=ffffffff
EBP=001318c0  FLG=00012206

------------------------------------------------------------

12-11-2002  09:00:06  SYS3175  PID 00f2  TID 0001  Slot 0082
H:\MOZILLA\BIN\MOZILLA.EXE
c0000005
06630367
P1=00000001  P2=06630367  P3=XXXXXXXX  P4=XXXXXXXX  
EAX=bddab0a3  EBX=01e4f10c  ECX=012f9080  EDX=00000000
ESI=00000000  EDI=00131850  
DS=0053  DSACC=f0f3  DSLIM=ffffffff  
ES=0053  ESACC=f0f3  ESLIM=ffffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:06630367  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0013182c  SSACC=f0f3  SSLIM=ffffffff
EBP=001318c0  FLG=00012286
MOZRMI36 traps don't provide us with any information and I can't recreate this
one at all.
I have this symptom too.
Mozilla nightlies have crashed 4 or 5 times per day on my MCP2 box since Dec 5.
Those crashes were almost "at random". Impossible to say how to recreate them.

By the way,
mrmazda, have you enabled the lifetime of cookies?

It may be ealier to say, workaround for this symptom is to disable
"Limit maximum lifetime of cookies to:".
I did enabled it and set 90 days fot lifetime. Since I disabled it a half day
ago, mozilla never crash.

Just happened again in 2002121112. Uptime of Mozilla prior to crash
approximately six hours. A page source window was open minimized in addition to
the browser, and possibly a mailnews window as well. Bookmarks file is
G:\mozilla\profiles\bookmarks.html 324K. Here's the last URI's in tabs that were
opened at crash:

1-certain-http://www.google.com/
2-certain-file:///G:/LIB/SYSDOC/ISP/IJ-helpindex.html
3-certain-http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&email1=mrmazda%40ij.net&emailtype1=exact&emailcc1=1&email2=&emailtype2=reg
4-certain-http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=1&votes=&chfield=%5BBug+creation%5D&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Browser&product=MailNews&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time
5-virtually_certain-file:///G:/WWW/css/interchange-n.html
6a-possible_open/probable_position-file:///G:/WWW/LIB/htmltaglist.html
6b-probable_open/probably_position-file:///G:/WWW/LIB/030text.htm#group
7-certain_as_tab_closed_causing_crash-http://bugzilla.mozilla.org/show_bug.cgi?id=130924

Depth of tabs above:
1-only
2-4th, all local files
3-first of two, reached via back button from
http://bugzilla.mozilla.org/buglist.cgi?email1=mrmazda%40ij.net&emailtype1=exact&emailreporter1=1
4-only
5-only
6-probably two, 6a then 6b
7-probably three, one being unknown opened from #4, then
http://bugzilla.mozilla.org/show_bug.cgi?id=124594, then above

During the 6 hours uptime, a number of other URI's were opened as last tabs and
then closed.

There could have been another tab open as 7, including 6b as additional rather
than opened in same tab, making the tab closed #8 rather than #7, or #9 rather
than #8. If there was another tab open between 6 & 7 above listed, a high
likelihood exists that it was opened from a (new bug) link in #4.

6a & 6b are locally saved copies of version 5 of
http://www.ncdesign.org/html/list.htm and
http://www.ncdesign.org/html/030text.htm#group. #5 is a newer, incomplete
version of http://members.ij.net/mrmazda/interchange.html. #2, an 804 byte
simple HTML file displaying no images, is available on request.
Cache settings: memory-8192; disk-10000.
On second thought, tab #1 probably had a depth of more than one, most likely a
single search for a history depth of two, from which a new tab >#6 had been
opened and closed.

Again, in 2002121112, abend right after closing rightmost tab at
http://www.iarchitect.com/tabs.htm. Uptime continuous since abend reported in
comment 3.
Hmm...my guess at comment 2 was wrong.
My mozilla still crashes even though lifetime of cookies is not limited.
Crashes are still "at random". Once I got SYS3175 in GKHTML.DLL when just
after I moved mozilla browser window by grabbing title bar.

My friend says that his mozilla os2 nightly build doesn't crash at all.
I have several crashes on two MCP2 boxes.
I still believe some differences between his preferences and mine give us
such different result.

Except for the URI in comment 6, I believe most, if not all, abends I
experienced followed shortly after clicking a Bugzilla "Commit" button on a
rightmost tab, indicating this may be the same behavior or related to bug 184931.
In 2002121212 I just got the abend closing bug 465 tab. It was 3rd from right of
7 or 8 tabs. Removing reference to last tab from summary.
Summary: OS/2 - abend on X (close) rightmost tab & remove focus → OS/2 - abend on X (close) tab & remove focus
Bug 184931 fix did not fix this. Still happening as of 2002121612, typically
closing a Bugzilla bug tab.
I have not had any crashes for this 24 hours.
OS2-2002121909 and OS2-2002121912 seem stable.
You are luckier than I. I just got the usual abend/trap X-ing the (rightmost)
tab containing http://www.cityofmarcoisland.com/ about 5 minutes ago. Total tabs
open: 8-10. Browser uptime, about 19 hours in 2002121912.
Are you saying this only happens if the browser has been running for 19 hours?
If so, you won't see any of us looking at it.
Only? Of course not. But, it may require real world use to see, lots of apps
open and more than 10 minutes of Mozilla uptime, not a sterile lab machine with
nothing but Mozilla open with a pittance of tabs. Dupe hunting takes time.
That's when I'm most likely to see it, and only by taking focus from Mozilla
right after hitting the close tab X.
2003011512 three times in under 24 hours, the last two separated by under four
minutes, both having been opened from the thumbnails at
http://rotarynews.com/view.php?id=150, which means long time running is not a
prerequisite. I tried to recreate after the second of the latter, but it since
refuses to crash. I suppose this may mean that the cache is likely involved?
How are things looking now?
The behavior was so obnoxious that I trained myself to avoid it. Now I always
select tab 3, 4 or 5 after closing the last tab, and/or make a conscious delay
before selecting another window. My last two Mozilla traps were Jan 27 & 30.
It's really annoying to hit the close tab X once, loose 18 tabs, and butcher the
history.

I haven't seen this behavior in quite some time, so marking WFM as of prior to
1.4b final.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.