Closed Bug 909467 Opened 6 years ago Closed 6 years ago

HTMLInputElement crash loading 8bit.js test

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla27
Tracking Status
firefox25 --- unaffected
firefox26 --- affected

People

(Reporter: rillian, Assigned: jwatt)

References

Details

Attachments

(2 files)

Trying the testcase for bug 908669, I hit a MOZ_CRASH on MacOS 10.7.5. Built from git commit b2bc29f994e6d983872b870d016550933a0b93f9, "Merge inbound to m-c" this morning.
...
WARNING: NS_ENSURE_TRUE(mTextInputHandler) failed: file /Users/giles/mozilla/firefox/widget/cocoa/nsChildView.mm, line 5084
WARNING: NS_ENSURE_TRUE(mTextInputHandler) failed: file /Users/giles/mozilla/firefox/widget/cocoa/nsChildView.mm, line 5084
++DOMWINDOW == 14 (0x122add8b8) [serial = 14] [outer = 0x121ff18b8]
JavaScript warning: http://code.angularjs.org/1.2.0rc1/angular.min.js, line 183: Using //@ to indicate source map URL pragmas is deprecated. Use //# instead
Hit MOZ_CRASH() at /Users/giles/mozilla/firefox/memory/mozjemalloc/jemalloc.c:1572

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
jemalloc_crash () at /Users/giles/mozilla/firefox/memory/mozjemalloc/jemalloc.c:1572
1572		MOZ_CRASH();
(gdb) bt
#0  jemalloc_crash () at /Users/giles/mozilla/firefox/memory/mozjemalloc/jemalloc.c:1572
#1  0x0000000100030614 in arena_run_reg_dalloc (run=0x124e74000, bin=0x100300360, ptr=0x124e74c58, size=80) at /Users/giles/mozilla/firefox/memory/mozjemalloc/jemalloc.c:3307
#2  0x000000010002c83e in arena_dalloc_small (arena=0x100300040, chunk=0x124e00000, ptr=0x124e74c58, mapelm=0x124e00b10) at /Users/giles/mozilla/firefox/memory/mozjemalloc/jemalloc.c:4518
#3  0x0000000100021bd6 in arena_dalloc (ptr=0x124e74c58, offset=478296) at /Users/giles/mozilla/firefox/memory/mozjemalloc/jemalloc.c:4646
#4  0x00000001000217a7 in je_free (ptr=0x124e74c58) at /Users/giles/mozilla/firefox/memory/mozjemalloc/jemalloc.c:6556
#5  0x0000000100025def in ozone_free_definite_size (zone=0x100070000, ptr=0x124e74c58, size=80) at /Users/giles/mozilla/firefox/memory/mozjemalloc/jemalloc.c:7051
#6  0x00007fff8dd18789 in free ()
#7  0x00000001000d2545 in moz_free (ptr=0x124e74c58) at /Users/giles/mozilla/firefox/memory/mozalloc/mozalloc.cpp:48
#8  0x0000000101652ab5 in nsTArrayInfallibleAllocator::Free (ptr=0x124e74c58) at nsTArray.h:209
#9  0x00000001021bf9fd in nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyElements<StringBuilder::Unit> >::~nsTArray_base (this=0x7fff5fbfbc98) at nsTArray-inl.h:20
#10 0x00000001021bf962 in nsTArray_Impl<StringBuilder::Unit, nsTArrayInfallibleAllocator>::~nsTArray_Impl (this=0x7fff5fbfbc98) at nsTArray.h:748
#11 0x00000001021bf935 in nsTArray<StringBuilder::Unit>::~nsTArray (this=0x7fff5fbfbc98) at nsTArray.h:1622
#12 0x00000001021bf915 in nsAutoArrayBase<nsTArray<StringBuilder::Unit>, 1020u>::~nsAutoArrayBase (this=0x7fff5fbfbc98) at nsTArray.h:1661
#13 0x00000001021bf8f5 in nsAutoTArray<StringBuilder::Unit, 1020u>::~nsAutoTArray (this=0x7fff5fbfbc98) at nsTArray.h:1732
#14 0x00000001021bf8d5 in nsAutoTArray<StringBuilder::Unit, 1020u>::~nsAutoTArray (this=0x7fff5fbfbc98) at nsTArray.h:1732
#15 0x00000001021bf88c in StringBuilder::~StringBuilder (this=0x7fff5fbfbc98) at /Users/giles/mozilla/firefox/content/base/src/Element.cpp:2503
#16 0x00000001021bf835 in StringBuilder::~StringBuilder (this=0x7fff5fbfbc98) at /Users/giles/mozilla/firefox/content/base/src/Element.cpp:2501
#17 0x00000001057c29d9 in WebCore::Decimal::toString (this=0x7fff5fbfbf78) at /Users/giles/mozilla/firefox/mfbt/decimal/Decimal.cpp:1033
#18 0x00000001057c2a7e in WebCore::Decimal::toString (this=0x7fff5fbfbf78, strBuf=0x7fff5fbfbda0 "", bufLength=32) at /Users/giles/mozilla/firefox/mfbt/decimal/Decimal.cpp:1038
#19 0x000000010259b8a0 in mozilla::dom::HTMLInputElement::SanitizeValue (this=0x122b76f10, aValue=@0x7fff5fbfc060) at /Users/giles/mozilla/firefox/content/html/content/src/HTMLInputElement.cpp:3670
#20 0x0000000102596958 in mozilla::dom::HTMLInputElement::SetValueInternal (this=0x122b76f10, aValue=@0x7fff5fbfc150, aUserInput=false, aSetValueChanged=false) at /Users/giles/mozilla/firefox/content/html/content/src/HTMLInputElement.cpp:2216
#21 0x00000001025a7c2f in mozilla::dom::HTMLInputElement::DoneCreatingElement (this=0x122b76f10) at /Users/giles/mozilla/firefox/content/html/content/src/HTMLInputElement.cpp:4692
#22 0x0000000102d98212 in nsHtml5TreeOperation::Perform (this=0x1235ff7d8, aBuilder=0x1233ac1e0, aScriptElement=0x7fff5fbfd248) at /Users/giles/mozilla/firefox/parser/html/nsHtml5TreeOperation.cpp:609
#23 0x0000000102d8f97a in nsHtml5TreeOpExecutor::RunFlushLoop (this=0x1233ac1e0) at /Users/giles/mozilla/firefox/parser/html/nsHtml5TreeOpExecutor.cpp:557
#24 0x0000000102d935d4 in nsHtml5ExecutorReflusher::Run (this=0x12395dbe0) at /Users/giles/mozilla/firefox/parser/html/nsHtml5TreeOpExecutor.cpp:61
#25 0x00000001046cd013 in nsThread::ProcessNextEvent (this=0x100467b70, mayWait=false, result=0x7fff5fbfd493) at /Users/giles/mozilla/firefox/xpcom/threads/nsThread.cpp:622
#26 0x0000000104625f5c in NS_ProcessPendingEvents (thread=0x100467b70, timeout=20) at nsThreadUtils.cpp:188
#27 0x00000001038eaf7f in nsBaseAppShell::NativeEventCallback (this=0x10f2cb600) at /Users/giles/mozilla/firefox/widget/xpwidgets/nsBaseAppShell.cpp:95
#28 0x00000001038532ac in nsAppShell::ProcessGeckoEvents (aInfo=0x10f2cb600) at /Users/giles/mozilla/firefox/widget/cocoa/nsAppShell.mm:388
#29 0x00007fff8dab54f1 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#30 0x00007fff8dab4d5d in __CFRunLoopDoSources0 ()
#31 0x00007fff8dadbb49 in __CFRunLoopRun ()
#32 0x00007fff8dadb486 in CFRunLoopRunSpecific ()
#33 0x00007fff975a92bf in RunCurrentEventLoopInMode ()
#34 0x00007fff975b056d in ReceiveNextEventCommon ()
#35 0x00007fff975b03fa in BlockUntilNextEventMatchingListInMode ()
#36 0x00007fff9288f779 in _DPSNextEvent ()
#37 0x00007fff9288f07d in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#38 0x0000000103851a57 in -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (self=0x100428c10, _cmd=0x7fff93167458, mask=18446744073709551615, expiration=0x422d63c37f00000d, mode=0x7fff7c41dae0, flag=1 '\001') at /Users/giles/mozilla/firefox/widget/cocoa/nsAppShell.mm:165
#39 0x00007fff9288b9b9 in -[NSApplication run] ()
#40 0x0000000103853d81 in nsAppShell::Run (this=0x10f2cb600) at /Users/giles/mozilla/firefox/widget/cocoa/nsAppShell.mm:742
#41 0x000000010343c1cc in nsAppStartup::Run (this=0x10f2f5150) at /Users/giles/mozilla/firefox/toolkit/components/startup/nsAppStartup.cpp:269
#42 0x0000000101571502 in XREMain::XRE_mainRun (this=0x7fff5fbff1c0) at /Users/giles/mozilla/firefox/toolkit/xre/nsAppRunner.cpp:3863
#43 0x0000000101571cf9 in XREMain::XRE_main (this=0x7fff5fbff1c0, argc=5, argv=0x7fff5fbffac0, aAppData=0x7fff5fbff458) at /Users/giles/mozilla/firefox/toolkit/xre/nsAppRunner.cpp:3931
#44 0x000000010157215d in XRE_main (argc=5, argv=0x7fff5fbffac0, aAppData=0x7fff5fbff458, aFlags=0) at /Users/giles/mozilla/firefox/toolkit/xre/nsAppRunner.cpp:4133
#45 0x00000001000022c7 in do_main (argc=5, argv=0x7fff5fbffac0, xreDirectory=0x100407740) at /Users/giles/mozilla/firefox/browser/app/nsBrowserApp.cpp:275
#46 0x0000000100001801 in main (argc=5, argv=0x7fff5fbffac0) at /Users/giles/mozilla/firefox/browser/app/nsBrowserApp.cpp:635
Are we managing to double-free somehow?
Flags: needinfo?(jwatt)
Duplicate of this bug: 911500
The linking is messed up (I'm not sure what change caused that, but it didn't used to be the case back when I was working on this code).

https://mxr.mozilla.org/mozilla-central/source/mfbt/decimal/Decimal.cpp?mark=968,970&rev=740094c07328#967

At the first marked line we're linking against the StringBuilder ctor defined in content/base/src/Element.cpp:

http://mxr.mozilla.org/mozilla-central/source/content/base/src/Element.cpp?rev=740094c07328#2494

Two lines later at the second marked line we're linking against the StringBuilder::append() defined in mfbt/decimal/moz-decimal-utils.h:

http://mxr.mozilla.org/mozilla-central/source/mfbt/decimal/moz-decimal-utils.h?rev=740094c07328#89

The StringBuilder dtor that is used is then the one for the StringBuilder in Element.cpp.

The ctor and dtor are being invoked on a block of memory that doesn't match the size of the block of memory that the compiler sets aside for the StringBuilder in Decimal::toString() when that method is compiled.
Assignee: nobody → jwatt
Flags: needinfo?(jwatt)
Ouch.  That sounds ... very broken.  :(
Attached patch patchSplinter Review
Attachment #801927 - Flags: review?(jwalden+bmo)
Waldo: I've taken moz-decimal-utils.h out of the patch series since it's not an imported file, and it's a complete pain in the neck to have it in there (it makes it much harder to change things and then refresh the patches).
(In reply to Boris Zbarsky [:bz] from comment #5)
> Ouch.  That sounds ... very broken.  :(

Yes, the fact that we now have four different "StringBuilder" classes in the tree makes it very undesirable to have any of them in the global namespace. After this patch the namespaces for the StringBuilders in the following files is:

  mfbt/double-conversion/utils.h      double_conversion
  mfbt/decimal/moz-decimal-utils.h    moz_decimal_utils
  xpcom/ds/StringBuilder.h            mozilla
  content/base/src/Element.cpp        <global>
It's probably a good idea to also put the StringBuilder in Element.cpp into the anonymous namespace (as opposed to the global namespace) to prevent anything outside that file from accidentally being linked against it again.
Attachment #801941 - Flags: review?(bzbarsky)
Comment on attachment 801941 [details] [diff] [review]
additional patch for Element.cpp

r=me, but is there no way to prevent this sort of thing from happeningat other callsites other than using anonymous namespaces?
Attachment #801941 - Flags: review?(bzbarsky) → review+
(In reply to Boris Zbarsky [:bz] from comment #10)
> is there no way to prevent this sort of thing from happeningat
> other callsites other than using anonymous namespaces?

Not that I know of.
(In reply to comment #11)
> (In reply to Boris Zbarsky [:bz] from comment #10)
> > is there no way to prevent this sort of thing from happeningat
> > other callsites other than using anonymous namespaces?
> 
> Not that I know of.

See <http://en.wikipedia.org/wiki/One_Definition_Rule>.  C++ requires the definitions for the same type to be the same across translation units, and does not require implementations to diagnose violations of ODR.  The linker, when faced with multiple definitions of any such function, picks one that it likes, at least in some circumstances. :(
Comment on attachment 801927 [details] [diff] [review]
patch

Review of attachment 801927 [details] [diff] [review]:
-----------------------------------------------------------------

Fugly.  Guess we'll have to keep in mind with these things in the future that our extra changes should be in a namespace, as a general rule, to avoid conflicts over similarly-reused names.
Attachment #801927 - Flags: review?(jwalden+bmo) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/3a520435e844
OS: Mac OS X → All
Hardware: x86_64 → All
Whiteboard: [leave open]
https://hg.mozilla.org/mozilla-central/rev/3a520435e844

Is it possible to test this somehow?
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
The page is simple enough, but I can't reproduce it reliably in other builds, so I don't think we can add a regression test.
Flags: in-testsuite? → in-testsuite-
Duplicate of this bug: 912634
Duplicate of this bug: 915253
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.