Closed Bug 245916 Opened 20 years ago Closed 20 years ago

crash loading gmail [@ nsSupportsWeakReference::GetWeakReference]

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set
critical

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?
Jay, are we seeing this high on the topcrash list?
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-
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=314001
(18a1 crash)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
this happens with me too except its linux  
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.
(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.
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?
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)                          = ?
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?
sorry for all the email.  FYI, the update I installed is at:
http://www.suse.com/us/private/download/updates/91_i386.html
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
Crash Signature: [@ nsSupportsWeakReference::GetWeakReference]
You need to log in before you can comment on or make changes to this bug.