Closed Bug 24552 Opened 25 years ago Closed 25 years ago

browser buster only loads a few urls before crashing.

Categories

(SeaMonkey :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: chofmann, Assigned: chofmann)

References

()

Details

(Keywords: crash)

At 11:41 AM -0800 1/20/00, Chris Hofmann wrote:
>I'm not able to keep browser buster running very long in release builds
>for the last couple of days.  There are two know[n] bugs. ...
>but there also seems to be a general page loading/refresh problem.
>Does anyone else see this in builds from the tip?

Greg Noel wrote:
I'm glad it's not just me.  I've been seeing this for two or three days,
but I've had enough other problems that I wasn't sure if it was a generic
issue.

The first page loads fine, but when it's about time for the refresh, the
browser crashes.  This happens for both a debug and an optimized build.

The crash does not cause a core dump, so I can't get a backtrace.  My gdb
is also acting up (it's complaining about a ptrace failure when the first
thread splits off), so I can't run it under a debugger, either.

I'm running MkLinux (a PPC-based Linux implementation) on a Mac 8500/150.

more from chofmann:
On todays linux release build this is what I see after
trying to load a url or two.

Program received signal SIGSEGV, Segmentation fault
0x20303220 in ?? ()
(gdb) where
#1  0x40dc6ca5 in NSGetModule ()
#2  0x40d026ff in NSGetModule ()
#3  0x40d9861e in NSGetModule ()
#4  0x40dc7419 in NSGetModule ()
#5  0x40d98750 in NSGetModule ()
#6  0x400fb61f in nsCOMPtr_base::~nsCOMPtr_base ()
#7  0x40dcdce7 in NSGetModule ()
#8  0x40dcd925 in NSGetModule ()
#9  0x400fb66f in nsCOMPtr_base::assign_with_AddRef ()
#10 0x408a9d2f in nsWebShell::Destroy ()
#11 0x40cfc92b in NSGetModule ()
#12 0x40c5317e in NSGetModule ()
#13 0x40dd2e78 in NSGetModule ()
#14 0x40c50d7f in NSGetModule ()
#15 0x40dd2e78 in NSGetModule ()
#16 0x40c50d7f in NSGetModule ()
#17 0x40dd2e78 in NSGetModule ()
#18 0x40c50d7f in NSGetModule ()
#19 0x40c66008 in NSGetModule ()
#20 0x40c488f3 in NSGetModule ()
#21 0x40c4682e in NSGetModule ()
#22 0x40dd2e78 in NSGetModule ()
#23 0x40c50d7f in NSGetModule ()
#24 0x40dd2e78 in NSGetModule ()
#25 0x40c50d7f in NSGetModule ()
#26 0x40c7db69 in NSGetModule ()
#27 0x40c56a8a in NSGetModule ()
#28 0x40c56a1c in NSGetModule ()
#29 0x40c6ecef in NSGetModule ()
#30 0x40c6e9b9 in NSGetModule ()
#31 0x400fb61f in nsCOMPtr_base::~nsCOMPtr_base ()
#32 0x40dcdca3 in NSGetModule ()
#33 0x40dcd925 in NSGetModule ()
#34 0x400fb66f in nsCOMPtr_base::assign_with_AddRef ()
#35 0x408a347e in nsWebShell::Embed ()
#36 0x408a5b56 in nsWebShell::CreateViewer ()
#37 0x408a58b7 in nsWebShell::DoContent ()
#38 0x406a2281 in NSGetModule ()
#39 0x406a1e3f in NSGetModule ()
#40 0x40fbeb33 in NSGetModule ()
#41 0x40fbe5e9 in NSGetModule ()
#42 0x40481983 in NSGetModule ()
#43 0x404812c0 in NSGetModule ()
#44 0x4012ec17 in PL_HandleEvent ()
#45 0x4012eb86 in PL_ProcessPendingEvents ()
#46 0x400f5dba in nsEventQueueImpl::ProcessPendingEvents ()
#47 0x404f9bef in nsAppShell::SetDispatchListener ()
This also affects me on MkLinux (a PPC-based Linux system), so it's more than 
just a PC/Windows issue.  Updating platform/OS to reflect this.
OS: Windows 95 → All
Hardware: PC → All
Severity: normal → critical
this morning's linux build is looking significantly better.  I've been running 
the browser buster about 15 minutes so far with no crashes, whereas earlier 
builds this week wouldn't last more than a minute or two.
win32 1/21 builds are also looking better - 
page counter cookie not updating (win32) and showing "NAN" (linux) is
still a problem but that is another bug.

anyone else see the crashing after updating to the tip or
grabbing a 1/21 build?

hard to figure out which check in from yesterday might have fixed
this.  maybe the bits just needed a good shaking..
Assignee: nobody → chofmann
 I could crash on first reload everytime with 2000-01-20 build, but
I'm fine with 2000-01-21 build (win95).

  I had a very simple testcase that was a minimal frameset with two
frames -- one src was 'text/html', the other 'text/plain' -- the key
thing being that the crash would only occur if one frame had content 
of 'text/plain' ... as in './test100/url.70'.
vidur mentioned a check-in in bug 24483, sounds related
*** Bug 24548 has been marked as a duplicate of this bug. ***
fixed by vidur
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Adding crash keyword
Keywords: crash
*spam* changing qa contact from nobody@mozilla.org to me (BlakeR1234@aol.com) 
on 121 open or resolved (but not verified) bugs.  sorry for the spam everybody, 
but most of these bugs would just remain dormant and not checked by QA 
otherwise.  I'm not sure how so many bugs have nobody as their QA contact, but 
I suspect this is the fault of some sort of bugzilla corruption that happened 
at some point (most of these bugs are in the 20000-26000 range, and I don't see 
where in the activity log that QA contact explicitly changed to 
nobody@mozilla.org)

Anyways, sorry again for spam.  If you really get annoyed, I'm usually 
available in #mozilla on IRC for torture.
QA Contact: nobody → BlakeR1234
QA assigning to doron to verify
QA Contact: blakeross → doronr
Product: Browser → Seamonkey
Blocks: 1093320
You need to log in before you can comment on or make changes to this bug.