Closed
Bug 115561
Opened 23 years ago
Closed 22 years ago
SEGV under linux (2001-12-12)
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: duvall, Assigned: scc)
Details
(Keywords: crash)
Attachments
(3 files)
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•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
Component: Browser-General → String
Comment 4•23 years ago
|
||
To string for real
Assignee: asa → scc
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
QA Contact: doronr → jaggernaut
Comment 5•23 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•23 years ago
|
||
Disregard the last post. We did a fresh build and are no longer seeing the crash.
Reporter | ||
Comment 7•23 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•22 years ago
|
||
closing as per comments above
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•3 years ago
|
Component: String → XPCOM
You need to log in
before you can comment on or make changes to this bug.
Description
•