115561 - SEGV under linux (2001-12-12)

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Danek Duvall]

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).

Comment 1

[Danek Duvall]

Attachment: backtrace

Comment 2

[Danek Duvall]

Attachment: 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.

Comment 3

[Danek Duvall]

Attachment: 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
}

Comment 4

[Boris Zbarsky [:bzbarsky]]

To string for real

Comment 5

[Philip K. Warren]

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

[Philip K. Warren]

Disregard the last post. We did a fresh build and are no longer seeing the crash.

Comment 7

[Danek Duvall]

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.

Comment 8

[Scott Collins]

closing as per comments above