Last Comment Bug 711602 - "ASSERTION: bad size recorded" with mozVibrate
: "ASSERTION: bad size recorded" with mozVibrate
Status: RESOLVED FIXED
: assertion, testcase
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86_64 Mac OS X
: -- normal (vote)
: mozilla11
Assigned To: Justin Lebar (not reading bugmail)
:
Mentors:
Depends on:
Blocks: 326633 706958
  Show dependency treegraph
 
Reported: 2011-12-16 13:47 PST by Jesse Ruderman
Modified: 2011-12-21 04:38 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (45 bytes, text/html)
2011-12-16 13:47 PST, Jesse Ruderman
no flags Details
Assertions from mochitest logs (14.75 KB, text/plain)
2011-12-19 11:41 PST, Justin Lebar (not reading bugmail)
no flags Details
Patch v1 (1.41 KB, patch)
2011-12-19 11:48 PST, Justin Lebar (not reading bugmail)
benjamin: review+
Details | Diff | Splinter Review

Description Jesse Ruderman 2011-12-16 13:47:14 PST
Created attachment 582380 [details]
testcase

###!!! ASSERTION: bad size recorded: 'aInstanceSize == 0 || entry->GetClassSize() == aInstanceSize', file /builds/slave/m-cen-osx64-dbg/build/xpcom/base/nsTraceRefcntImpl.cpp, line 473

NS_LogAddRef_P [xpcom/base/nsTraceRefcntImpl.cpp:998]
mozilla::ClearOnShutdown_Internal::ShutdownObserver<nsAutoPtr<InfallibleTArray<long long unsigned int> > >::AddRef [down.h:79]
nsObserverList::AddObserver [nsCOMPtr.h:889]
mozilla::ClearOnShutdown<nsAutoPtr<InfallibleTArray<long long unsigned int> > > [:519]
mozilla::hal::Vibrate [hal/Hal.cpp:115]
mozilla::dom::Navigator::MozVibrate [nsCOMPtr.h:519]
NS_InvokeByIndex_P [xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:197]

###!!! ASSERTION: bad size recorded: 'aInstanceSize == 0 || entry->GetClassSize() == aInstanceSize', file /builds/slave/m-cen-osx64-dbg/build/xpcom/base/nsTraceRefcntImpl.cpp, line 473

NS_LogAddRef_P [xpcom/base/nsTraceRefcntImpl.cpp:998]
mozilla::ClearOnShutdown_Internal::ShutdownObserver<nsRefPtr<mozilla::dom::<unnamed>::VibrateWindowListener> >::AddRef [ClearOnShutdown.h:79]
nsObserverList::FillObserverArray [nsCOMPtr.h:880]
nsObserverList::NotifyObservers [xpcom/ds/nsObserverList.cpp:127]
nsObserverService::NotifyObservers [nsTHashtable.h:163]
mozilla::ShutdownXPCOM [xpcom/glue/nsCOMPtr.h:519]
ScopedXPCOMStartup::~ScopedXPCOMStartup [toolkit/xre/nsAppRunner.cpp:1115]
XRE_main [nsCOMPtr.h:807]
main [browser/app/nsBrowserApp.cpp:201]

Tested with http://hg.mozilla.org/mozilla-central/rev/7cc472108eb4
Comment 1 Justin Lebar (not reading bugmail) 2011-12-19 08:28:32 PST
This is almost surely a result of the NS_ISUPPORTS implementation hack I have for ClearOnShutdown<T>.  Sigh.
Comment 2 Justin Lebar (not reading bugmail) 2011-12-19 11:32:21 PST
Hm, I can't reproduce with a local debug, trace-malloc build, rev 7ccc472.  I verified that ClearOnShutdown is being called.
Comment 3 Justin Lebar (not reading bugmail) 2011-12-19 11:39:28 PST
I do see this in the mochitest-3 logs, however.
Comment 4 Justin Lebar (not reading bugmail) 2011-12-19 11:41:48 PST
Created attachment 582899 [details]
Assertions from mochitest logs

Not the same stacks as in comment 0, strangely.
Comment 5 Justin Lebar (not reading bugmail) 2011-12-19 11:43:52 PST
Maybe the trace refcnt assertions just aren't on when I run dist/bin/firefox?  I see the assertions when I run the vibrator mochitest locally.
Comment 6 Justin Lebar (not reading bugmail) 2011-12-19 11:48:33 PST
Created attachment 582902 [details] [diff] [review]
Patch v1

Reading through the implementation of INLINE_REFCOUNTING and DECL_{ADDREF,RELEASE}, it's not entirely clear to me why this works.  But it does seem to work.
Comment 7 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-12-19 12:21:55 PST
Comment on attachment 582902 [details] [diff] [review]
Patch v1

This turns out to just be a name collision with the other ShutdownObserver in gfx-land.
Comment 8 Justin Lebar (not reading bugmail) 2011-12-19 12:23:41 PST
I'll fully qualify the class name in the NS_IMPL macros.
Comment 9 Justin Lebar (not reading bugmail) 2011-12-19 13:23:35 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/dd2f9236b591
Comment 10 Justin Lebar (not reading bugmail) 2011-12-19 13:51:48 PST
Verified that there's no assertion in https://tbpl.mozilla.org/php/getParsedLog.php?id=8039971&tree=Mozilla-Inbound
Comment 11 Ed Morley [:emorley] 2011-12-20 05:55:13 PST
https://hg.mozilla.org/mozilla-central/rev/dd2f9236b591
Comment 12 Jesse Ruderman 2011-12-20 18:30:04 PST
(In reply to Justin Lebar [:jlebar] from comment #5)
> Maybe the trace refcnt assertions just aren't on when I run
> dist/bin/firefox?  I see the assertions when I run the vibrator mochitest
> locally.

I see the assertion (in an old build) if I run with XPCOM_MEM_LEAK_LOG=2.
Comment 13 Ted Mielczarek [:ted.mielczarek] 2011-12-21 04:38:04 PST
Yes, refcnt logging isn't enabled by default, you have to set an environment variable to enable it. Mochitest does this by default:
http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/runtests.py#543

Note You need to log in before you can comment on or make changes to this bug.