783998 - crash in nsHtml5RefPtrReleaser

Status: RESOLVED DUPLICATE of bug 902158

(Thunderbird :: General, defect)

Description

[Wayne Mery (:wsmwk)]

This bug was filed from the Socorro interface and is 
report bp-b2cd725a-fbcd-4a13-b5e1-651742120819 .
============================================================= 
0	xul.dll	nsHtml5RefPtrReleaser<nsHtml5StreamParser>::Run	parser/html/nsHtml5RefPtr.h:57
1	xul.dll	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:657
2	xul.dll	NS_ProcessNextEvent_P	objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp:245
3	xul.dll	nsThread::Shutdown	xpcom/threads/nsThread.cpp:499
4	xul.dll	nsRunnableMethodImpl<unsigned int 	objdir-tb/mozilla/dist/include/nsThreadUtils.h:345 

~40% crashes are startup.
some are shutdown, as noted in bp-b2cd725a-fbcd-4a13-b5e1-651742120819 

55 NS_IMETHODIMP Run()
56 {
57 mPtr->Release(); 


firefox example bp-90068020-6266-46eb-92d3-55d372120810

Comment 1

[Henri Sivonen (:hsivonen) (on vacation)]

> firefox example bp-90068020-6266-46eb-92d3-55d372120810

The stack in this report is completely bogus.

Hopefully the need to worry about the shutdown case goes away once we start quitting with exit(0).

Comment 2

[Wayne Mery (:wsmwk)]

only about 2 per month per version
bp-3802836e-b833-48b9-9ab7-10a6b2130517 TB21

Comment 3

[Hiroyuki Ikezoe (:hiro)]

There are still lots of reports of this crash on Thunderbird but I am now convinced that the stack trace is wrong.

The correct must be nsProxyReleaseEvent::Run():

class nsProxyReleaseEvent : public nsRunnable
{
public:
  explicit nsProxyReleaseEvent(nsISupports* aDoomed) : mDoomed(aDoomed) {}

  NS_IMETHOD Run()
  {
    mDoomed->Release();
    return NS_OK;
  }

private:
  nsISupports* mDoomed;
};

I am not sure why nsHtml5Parser does not use nsMainThreadPtrHandle though.

I am also convinced that the cause of this crash is the same as bug 902158.

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
> There are still lots of reports of this crash on Thunderbird 

Actually, this crash sig is RARE in thunderbird prior to 31.1.2 where it increased about ten-fold
- version 31.1.2 ~500 crashes per week (build 2014092320)
- no 31.1.1, 31.0 or 31.1.0 crashes
- version 24.6.0 ~50 crashes per week


> but I am now
> convinced that the stack trace is wrong.
> 
> The correct must be nsProxyReleaseEvent::Run():
> 
> class nsProxyReleaseEvent : public nsRunnable
> {
> public:
>   explicit nsProxyReleaseEvent(nsISupports* aDoomed) : mDoomed(aDoomed) {}
> 
>   NS_IMETHOD Run()
>   {
>     mDoomed->Release();
>     return NS_OK;
>   }
> 
> private:
>   nsISupports* mDoomed;
> };
> 
> I am not sure why nsHtml5Parser does not use nsMainThreadPtrHandle though.

do you suspect a bug that needs a report?

> I am also convinced that the cause of this crash is the same as bug 902158.

Indeed many signatures will probably go away after bug 902158 is fixed. I'm looking forward to it :)

Comment 5

[Josh Matthews [:jdm]]

nsMainThreadPtrHandle is much newer than the HTML parser main-thread smart pointer types.

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
> There are still lots of reports of this crash on Thunderbird but I am now
> convinced that the stack trace is wrong.
> 
> The correct must be nsProxyReleaseEvent::Run():
> 
> class nsProxyReleaseEvent : public nsRunnable
> {
> public:
>   explicit nsProxyReleaseEvent(nsISupports* aDoomed) : mDoomed(aDoomed) {}
> 
>   NS_IMETHOD Run()
>   {
>     mDoomed->Release();
>     return NS_OK;
>   }
> 
> private:
>   nsISupports* mDoomed;
> };
> 
> I am not sure why nsHtml5Parser does not use nsMainThreadPtrHandle though.
> (jdm) nsMainThreadPtrHandle is much newer than the HTML parser main-thread smart pointer types.

> I am also convinced that the cause of this crash is the same as bug 902158.

I didn't follow up in a timely fashion, so I don't know how the crash rate changed when 902158 was fixed.  So trusting hiro's analysis.  (note however, nsHtml5Parser crashes exist, or did until 45.3.0, so perhaps these were a different issue)