SEGV under linux (2001-12-12)

RESOLVED FIXED

Status

()

Core
String
--
critical
RESOLVED FIXED
16 years ago
15 years ago

People

(Reporter: Danek Duvall, Assigned: Scott Collins)

Tracking

({crash})

Trunk
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
With a 2001-12-12 build on Linux, I've been getting random segfaults, usually
when the browser's been idle for some time.  This might be related to bug
114910, but the backtrace is different.  I'll attach the backtrace (attching to
avoid linewrap).
(Reporter)

Comment 1

16 years ago
Created attachment 61930 [details]
backtrace
(Reporter)

Comment 2

16 years ago
Created attachment 62065 [details]
another backtrace

Here's another backtrace.  Note that the top eight frames are the same.  I'll
see if I can create a debugging build of the same date to track down a more
detailed trace.
(Reporter)

Comment 3

16 years ago
Created attachment 62170 [details]
backtrace 3 (with debugging info)

Here's a backtrace that actually gives us line numbers.  It looks like in frame
8, old_handle is garbage:

(gdb) p *old_handle
$25 = {
    <nsBufferHandle<char>> = {
	mDataStart = 0x89b37f8 "i",
	mDataEnd = 0x406ecc18
"8\nÉ\bH\004\227\bHÏ\006\b¨×y\bøkh\b07\025\bX\177e\b\bBc\bX\024\224\b\210\031\223\b@«\200\b\b³m\b"

    }
	mFlags = 0,
	mStorageLength = 0
}
(Reporter)

Updated

16 years ago
Component: Browser-General → String
To string for real
Assignee: asa → scc
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
QA Contact: doronr → jaggernaut

Comment 5

16 years ago
We are seeing similar behavior on AIX with MOZILLA_0_9_8_BRANCH builds, which is
causing crashes on startup. Here is the stack trace we are seeing:

nsXPIDLString.ReleaseReference() const(0x2001b9e8), line 393 in "nsBufferHandle.h"
nsXPIDLString.operator=(const nsSharedBufferHandle<char>*)(0x2001b9b0,
0x2001ba48), line 74 in "nsBufferHandleUtils.h"
PrepareForUseAsOutParam()(0x2001b9ac), line 220 in "nsXPIDLString.cpp"
nsLocalFileUnix.Adopt(char*)(0x2001b9ac, 0x2001ba08), line 298 in "nsXPIDLString.h"
Normalize()(0x2001b928), line 486 in "nsLocalFileUnix.cpp"
GetCurrentProcessDirectory(nsILocalFile**)(0x2001b3c8, 0x2ff21e10), line 265 in
"nsDirectoryService.cpp"
unnamed block $b1813, line 804 in "nsDirectoryService.cpp"
GetFile(const char*,int*,nsIFile**)(0x2001b3c8, 0xd3b2d58c, 0x2ff21fe0,
0x2ff21fdc), line 804 in "nsDirectoryService.cpp"
unnamed block $b1807, line 655 in "nsDirectoryService.cpp"
FindProviderFile(nsISupports*,void*)(0x2001b3d0, 0x2ff21fd8), line 655 in
"nsDirectoryService.cpp"
Get(const char*,const nsID&,void**)(0x2001b3c8, 0xd3b2d58c, 0xd3b2d380,
0x2ff220a8), line 697 in "nsDirectoryService.cpp"
unnamed block $b2526, line 536 in "nsRegistry.cpp"
unnamed block $b2525, line 536 in "nsRegistry.cpp"
OpenWellKnownRegistry(int)(0x2001ff48, 0x1), line 536 in "nsRegistry.cpp"
PlatformInit()(0x2001fb08), line 682 in "nsComponentManager.cpp"
unnamed block $b2331, line 565 in "nsComponentManager.cpp"
Init()(0x2001fb08), line 565 in "nsComponentManager.cpp"
unnamed block $b1349, line 379 in "nsXPComInit.cpp"
NS_InitXPCOM2(0x0, 0x0, 0x0), line 379 in "nsXPComInit.cpp"
main(argc = 1, argv = 0x2ff224a8), line 1607 in "nsAppRunner.cpp"

Comment 6

16 years ago
Disregard the last post. We did a fresh build and are no longer seeing the crash.
(Reporter)

Comment 7

16 years ago
Yeah, I'm not seeing this either.  My crashes have gotten significantly less
frequent over the past few weeks, and none of the newer stack traces look like
this.  Pity we don't know what was going on, but the problem (knock on wood)
seems to be gone.
(Assignee)

Comment 8

15 years ago
closing as per comments above
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.