Closed
Bug 245916
Opened 20 years ago
Closed 20 years ago
crash loading gmail [@ nsSupportsWeakReference::GetWeakReference]
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: timeless, Unassigned)
References
()
Details
(Keywords: crash)
Crash Data
i just tried logging into gmail (new tab) and i crashed. there are bugs that
talk about threading hazards w/ mProxy, i /wonder/ if that relates.
nsSupportsWeakReference::GetWeakReference( nsIWeakReference** aInstancePtr )
{
if ( !aInstancePtr )
return NS_ERROR_NULL_POINTER;
if ( !mProxy )
mProxy = new nsWeakReference(this);
*aInstancePtr = mProxy;
nsresult status;
if ( !*aInstancePtr )
status = NS_ERROR_OUT_OF_MEMORY;
else
{
NS_ADDREF(*aInstancePtr); // crashing here
status = NS_OK;
}
return status;
}
- aInstancePtr 0x0012f660 nsIWeakReference * *
\- 0x054f4498 nsIWeakReference *
\- nsISupports {...} nsISupports
\+ __vfptr 0xfffdfffd *
- this 0x022f464c {mRefCnt={mValue=0x00000002 } mCaretEnabled=0x00000000
mBidiLevel=0x80 '€' ...} nsSupportsWeakReference * const
|+ [PresShell] {mRefCnt={mValue=0x00000002 } mCaretEnabled=0x00000000
mBidiLevel=0x80 '€' ...} PresShell
|+ nsISupportsWeakReference {...} nsISupportsWeakReference
\+ mProxy 0x054f4498 {mRefCount=0xfffdfffd mReferent=0xfffdfffd {mProxy=??? } }
nsWeakReference *
> xpcom.dll!nsSupportsWeakReference::GetWeakReference(nsIWeakReference * *
aInstancePtr=0x0012f660) Line 114 + 0x3 C++
xpcom.dll!nsGetWeakReference::operator()(const nsID & __formal={...}, void * *
aResult=0x00000000) Line 77 + 0xa C++
xpcom.dll!nsCOMPtr_base::assign_from_helper(const nsCOMPtr_helper &
helper={...}, const nsID & iid={...}) Line 114 + 0x10 C++
gklayout.dll!nsCOMPtr<nsIWeakReference>::operator=(const nsCOMPtr_helper &
rhs={...}) Line 644 C++
gklayout.dll!ReflowEvent::ReflowEvent(nsIPresShell * aPresShell=0x022f45c8)
Line 6258 C++
gklayout.dll!PresShell::PostReflowEvent() Line 6273 + 0x14 C++
gklayout.dll!PresShell::DidCauseReflow() Line 6311 C++
gklayout.dll!PresShell::InitialReflow(int aWidth=0x05857f70, int
aHeight=0x00000000) Line 2930 C++
gklayout.dll!nsContentSink::StartLayout(int aIsFrameset=0x00000000) Line 953 C++
gklayout.dll!HTMLContentSink::StartLayout() Line 3733 C++
gklayout.dll!HTMLContentSink::OpenBody(const nsIParserNode & aNode={...})
Line 2829 C++
gkparser.dll!CNavDTD::OpenBody(const nsCParserNode * aNode=0x027480c8) Line
3169 + 0x11 C++
gkparser.dll!CNavDTD::OpenContainer(const nsCParserNode * aNode=0x027480c8,
nsHTMLTag aTag=eHTMLTag_unknown, int aClosedByStartTag=0x00000001, nsEntryStack
* aStyleStack=0x00000000) Line 3406 C++
gkparser.dll!CNavDTD::HandleDefaultStartToken(CToken * aToken=0x0573e648,
nsHTMLTag aChildTag=eHTMLTag_a, nsCParserNode * aNode=0x027480c8) Line 1471 C++
gkparser.dll!CNavDTD::HandleStartToken(CToken * aToken=0x0000000f) Line
1847 + 0xe C++
gkparser.dll!CNavDTD::HandleToken(CToken * aToken=0x0573e648, nsIParser *
aParser=0x02c10008) Line 1031 + 0xa C++
gkparser.dll!CNavDTD::HandleToken(CToken * aToken=0x0573e600, nsIParser *
aParser=0x02c10008) Line 998 + 0xa C++
gkparser.dll!CNavDTD::BuildModel(nsIParser * aParser=0x02c10008, nsITokenizer
* aTokenizer=0x0573e600, nsITokenObserver * anObserver=0x00000000,
nsIContentSink * aSink=0x0568b464) Line 510 + 0xa C++
gkparser.dll!nsParser::BuildModel() Line 1898 C++
gkparser.dll!nsParser::ResumeParse(int allowIteration=0x00000001, int
aIsFinalChunk=0x00000000, int aCanInterrupt=0x00000001) Line 1760 + 0x6 C++
gkparser.dll!nsParser::OnDataAvailable(nsIRequest * request=0x05603058,
nsISupports * aContext=0x00000000, nsIInputStream * pIStream=0x054f4a00,
unsigned int sourceOffset=0x00000000, unsigned int aLength=0x00000021) Line
2425 + 0xd C++
docshell.dll!nsDocumentOpenInfo::OnDataAvailable(nsIRequest *
request=0x05603058, nsISupports * aCtxt=0x00000000, nsIInputStream *
inStr=0x054f4a00, unsigned int sourceOffset=0x00000000, unsigned int
count=0x00000021) Line 344 C++
necko.dll!nsHTTPCompressConv::do_OnDataAvailable(nsIRequest *
request=0x05603058, nsISupports * aContext=0x00000000, unsigned int
aSourceOffset=0x00000000, char * buffer=0x02c10290, unsigned int
aCount=0x00000000) Line 368 + 0x16 C++
necko.dll!nsHTTPCompressConv::OnDataAvailable(nsIRequest * request=0x05603058,
nsISupports * aContext=0x00000000, nsIInputStream * iStr=0x02943378, unsigned
int aSourceOffset=0x00000000, unsigned int aCount=0x00000033) Line 292 C++
necko.dll!nsHttpChannel::OnDataAvailable(nsIRequest * request=0x02b07300,
nsISupports * ctxt=0x00000000, nsIInputStream * input=0x02943378, unsigned int
offset=0x00000000, unsigned int count=0x00000033) Line 3703 C++
necko.dll!nsInputStreamPump::OnStateTransfer() Line 437 C++
necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *
stream=0x02943378) Line 338 C++
xpcom.dll!nsOutputStreamReadyEvent::EventHandler(PLEvent * plevent=0x057138dc)
Line 119 C++
xpcom.dll!PL_HandleEvent(PLEvent * self=0x057138dc) Line 693 C
xpcom.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00dc1638) Line 627
+ 0x6 C
xpcom.dll!_md_EventReceiverProc(HWND__ * hwnd=0x008b2be0, unsigned int
uMsg=0x0000c127, unsigned int wParam=0x00000000, long lParam=0x00dc1638) Line
1434 C
user32.dll!77d43a50()
user32.dll!77d43b1f()
user32.dll!GetMessageW() + 0x125
user32.dll!DispatchMessageW() + 0xb
appshell.dll!nsAppShellService::Run() Line 524 C++
mozilla.exe!main1(int argc=0x022f45c8, char * * argv=0x00000000, nsISupports *
nativeApp=0x054f4498) Line 1302 + 0x9 C++
mozilla.exe!main(int argc=0x00000001, char * * argv=0x002a41d0) Line 1779 +
0x16 C++
mozilla.exe!WinMain(HINSTANCE__ * __formal=0x00400000, HINSTANCE__ *
__formal=0x00400000, char * args=0x0015233e, HINSTANCE__ * __formal=0x00400000)
Line 1807 + 0x17 C++
mozilla.exe!WinMainCRTStartup() Line 392 + 0xf C
kernel32.dll!GetCurrentDirectoryW() + 0x44
I think you will find that this bug happens in any circumstance where the Gmail inbox or Gmail message is reloaded. Just hit the reload button and watch it crash. I've submitted several talkback bugs on this--all of which mention Gmail, so they should be easy to find. Submitter, please change the URL field to http://www.gmail.com or http://gmail.gmail.com.. so that we can track this. Once this bug is assigned, I will provide a Gmail account for troubleshooting purposes if it is needed, or as a logical reward after--whichever makes the most sense :-)
Flags: blocking1.8a2?
Comment 2•20 years ago
|
||
Jay, are we seeing this high on the topcrash list?
Comment 3•20 years ago
|
||
I'm unable to reproduce a crash after repeated loading of Gmail inbox on today's trunk SeaMonkey of Firefox builds. If this shows up high in talkbac, then Jay renominate and we'll reconsider.
Flags: blocking1.8a2? → blocking1.8a2-
The crash doesn't happen when using FireFox only with Mozilla. I have started using FireFox because of this. I just downloaded Mozilla 1.8a2 & tested it. The browser still crashes. Also the url is gmail.google.com
Comment 6•20 years ago
|
||
this happens with me too except its linux
Comment 7•20 years ago
|
||
i also have this problem on linux but not on windows version string where it works: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 version string where it doesn't: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 when running from the console i get no error message or feedback at all; the window simply disappears and i am returned to the prompt. jeremy@black:~> mozilla jeremy@black:~> I'm no mozilla guru but if there's any other feedback i can give to help let me know.
Comment 8•20 years ago
|
||
(In reply to comment #7) > i also have this problem on linux but not on windows > > version string where it works: > Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 Exactly the same, SUSE 9.1, Mozilla 1.6.74, version string: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 This bug does not affect Firefox 0.9.
Comment 9•20 years ago
|
||
Linux (SUSE 9.1), I did an strace and got this as the last bunch of lines: mmap2(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x43282000 gettimeofday({1095354742, 487701}, NULL) = 0 gettimeofday({1095354742, 489509}, NULL) = 0 gettimeofday({1095354742, 495225}, NULL) = 0 gettimeofday({1095354742, 496152}, NULL) = 0 gettimeofday({1095354742, 496797}, NULL) = 0 gettimeofday({1095354742, 496867}, NULL) = 0 gettimeofday({1095354742, 496937}, NULL) = 0 gettimeofday({1095354742, 497066}, NULL) = 0 gettimeofday({1095354742, 505186}, NULL) = 0 futex(0x8204024, FUTEX_WAKE, 1) = 1 futex(0x8204014, FUTEX_WAKE, 1) = 1 --- SIGSEGV (Segmentation fault) @ 0 (0) --- unlink("/home/runlevel0/.mozilla/default/g6ihbrzl.slt/lock") = 0 exit_group(11) = ? It dosn't say anything to me, except that a segfault occured, but I have the whole trace backed up. I used strace w/o flags (except for the file output)... Would it be of any help if I include the trace?
Comment 10•20 years ago
|
||
wow, good idea. i can confirm that strace output, i get exactly the same thing. seems like a seg fault ought to leave a core dump? if we could get a core dump then couldn't we get a stack trace that would tell us exactly which line of mozilla's code it's bombing on? from my machine: ... open("/home/jeremy/.mozilla/default/m6cmuhoo.slt/Cache/4691D49Ed01", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 41 write(41, "\37\213\10\0\0\0\0\0\0\0\344\275k[\333\272\3220\374}\377"..., 16384) = 16384 write(41, "\301T \230\223+\352\342\223\257\335/\224k\30\217\357\252"..., 16384) = 16384 write(41, "\1\377\335z1[$\235\346\360\22\242\274\371R\330\316\224"..., 16384) = 16384 mmap2(NULL, 159744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x42f91000 mmap2(NULL, 319488, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x42fb8000 gettimeofday({1095357174, 646835}, NULL) = 0 gettimeofday({1095357174, 653085}, NULL) = 0 gettimeofday({1095357174, 654022}, NULL) = 0 mmap2(NULL, 520192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x43006000 mmap2(NULL, 159744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x43085000 mmap2(NULL, 520192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x430ac000 brk(0) = 0x8925000 brk(0x8946000) = 0x8946000 brk(0) = 0x8946000 ...[repeated - edited by Jeremy]... brk(0) = 0x8b30000 brk(0x8b51000) = 0x8b51000 brk(0) = 0x8b51000 brk(0x8b74000) = 0x8b74000 gettimeofday({1095357174, 983790}, NULL) = 0 ...[repeated - edited by Jeremy]... gettimeofday({1095357174, 999278}, NULL) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- unlink("/home/jeremy/.mozilla/default/m6cmuhoo.slt/lock") = 0 exit_group(11) = ?
Comment 11•20 years ago
|
||
it's fixed for me now. i'm running SuSE 9.1 and just installed the mozilla security patch update. my mozilla is now at mozilla-1.6-74.14 and the bug is fixed. Under "Additional Bugs fixed" it says (among other things) "- Fixed crashing problem introduced by last security update." I don't remember what rpm version I had previously installed (it was 1.6-74.[something less than 14] ) but this has fixed the problem for me. The version string is still exactly the same from the "About Mozilla" page: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 did the update fix the problem for anyone else?
Comment 12•20 years ago
|
||
sorry for all the email. FYI, the update I installed is at: http://www.suse.com/us/private/download/updates/91_i386.html
Reporter | ||
Comment 13•20 years ago
|
||
runlevel0@gmail.com/jer1887-linux@yahoo.com: for future reference, please don't ever post strace output to bugzilla.mozilla.org unless someone asks you to. straces are almost always useless. if you're using a non mozilla.org build and have control over how it's built, see that it's built w/ --enable-debug or --enable-debugger-info-modules and without --enable-strip. then run your favorite gecko w/ -g, e.g.: ./mozilla -g from there you will normally get a gdb prompt. if you happen to get ddd and decide that perhaps debugging an x app that can grab your x cursor and thoroughly hose your x debugger is a bad idea, then you can add -d gdb to ask mozilla to use gdb specifically. at the gdb prompt, there are three important commands: run (start the app) bt (or where or backtrace - get a *STACK* trace) help (for information about the rest of gdb) there's a unix debugging faq which can provide further assistance. fwiw talkback doesn't show any trunk crashes since build 2004052009 (which would be 1.8a1)
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsSupportsWeakReference::GetWeakReference]
You need to log in
before you can comment on or make changes to this bug.
Description
•