905746 - Debug builds hit EXC_BAD_ACCESS (SIGSEGV) KERN_INVALID_ADDRESS at 0x00007fff5fc00000 (right before Assertion failure: fraction >= 0.0 && fraction <= 1.0, at layout/forms/nsRangeFrame.cpp:606)

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: callstack.txt

In Nightly Debug from mid-day m-c pull today.

STR: Open URL

Assertion failure: fraction >= 0.0 && fraction <= 1.0,
at /Users/Jan/moz/mozilla-central/layout/forms/nsRangeFrame.cpp:606

    nsSize thumbSize = aThumbFrame->GetSize();
    double fraction = GetValueAsFractionOfRange();
    MOZ_ASSERT(fraction >= 0.0 && fraction <= 1.0);

    nsSize thumbSize = aThumbFrame->GetSize();
    double fraction = GetValueAsFractionOfRange();
 -> MOZ_ASSERT(fraction >= 0.0 && fraction <= 1.0);

    // We are called under Reflow, so we need to pass IsHorizontal a valid rect.
    nsSize frameSizeOverride(aRangeSize.width, aRangeSize.height);

fraction = NaN. See attached trace. This worked yesterday.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

marking s-s per IRC chat

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: NightlyDebug quit unexpectedly.

I ran today's NightlyDebug outside of the debugger and followed STR and found it crashing right *before* the assert. From attached OSX crashdump:

  Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
  Exception Codes: KERN_INVALID_ADDRESS at 0x00007fff5fc00000

  Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

  0 libsystem_c.dylib memmove$VARIANT$sse42 + 211
  1   libstdc++.6.dylib std::string::_Rep::_M_clone(std::allocator<char>) + 81
  2   libstdc++.6.dylib std::string::reserve(unsigned long) + 62
  3   libstdc++.6.dylib std::string::append(char const*, unsigned long) + 101
  4   XUL StringBuilder::appendLiteral(char const*)+29 (moz-decimal-utils.h:94)
  5   XUL WebCore::Decimal::toString() const + 979 (Decimal.cpp:1012)
  6   XUL WebCore::Decimal::toDouble() const + 51 (Decimal.cpp:940)
  7   XUL nsRangeFrame::GetValueAsFractionOfRange()+771 (nsRangeFrame.cpp:455)
  8   XUL nsRangeFrame::DoUpdateThumbPosition(nsIFrame*, nsSize const&) + 215

Looks like a bad pointer read right ahead of the assert.

- If I run it in gdb or Xcode debugger then I get the assert hit instead.
- Both crash and assert only happen for me in NightlyDebug, not Nightly.

Comment 3

[Daniel Holbert [:dholbert]]

WFM with a Linux 64-bit up-to-date m-c debug build (based off of aada0f74faf9).

Maybe this is mac-specific? (also, are you hitting this in a fresh profile w/ no tweaks?)

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Nightly Mac (not debug); no problems loading that URL

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: with_new_profile.txt

> Maybe this is mac-specific?

Quite possible. I'm doing a debug build on windows now (opt worked fine).

> (also, are you hitting this in a fresh profile w/ no tweaks?)

Yes. To verify this, I created a fresh profile and tested it (output attached). I see some exceptions from BackgroundPageThumbs.jsm this time. Hmm, the crash is in DoUpdateThumbPosition... I wonder if that's related.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #5)
> I see some exceptions from BackgroundPageThumbs.jsm this time.
> Hmm, the crash is in DoUpdateThumbPosition... I wonder if that's related.

Nope, that's just coincidence -- it's relating to completely different "thumbs".(DoUpdateThumbPosition is for the "thumb" (the knob) that you drag to adjust the value of a <range> element.  In contrast, BackgroundPageThumbs.jsm is for making thumbnails of webpages in the background.)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Randell Jesup [:jesup] from comment #4)
> Nightly Mac (not debug); no problems loading that URL

(note that jib couldn't repro in non-debug builds, either, per end of comment 2)

Comment 8

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Comment on attachment 790986 [details]
NightlyDebug quit unexpectedly.

> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x00007fff5fc00000
>
> VM Regions Near 0x7fff5fc00000:
>  Stack 00007fff5f400000-00007fff5fc00000 [ 8192K] rw-/rwx SM=COW thread 0
> -->
>  __TEXT 00007fff676f8000-00007fff6772d000 [ 212K] r-x/rwx SM=COW /usr/lib/dyld

On closer examination, it looks like we blew the stack here (explains the round address and maybe why it only happens in debug?)

Comment 9

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: moz_decimal_utils.h::StringBuilder printf instrumentation (not a fix)

To pinpoint the problem, this patch adds printfs to mfbt/decimal/moz-decimal-utils.h::StringBuilder

Here's the output from three runs (opt build, debug build, gdb debug build):

1. Opt build - works fine:

  appendLiteral: StringBuilder.mStr = ""
  appendLiteral: StringBuilder.mStr = "0."
  append: StringBuilder.mStr = "0."
  append: StringBuilder.mStr = "0.234375"
  toString: StringBuilder.mStr = "0.234375"
  appendLiteral: StringBuilder.mStr = ""
  appendLiteral: StringBuilder.mStr = "0."
  append: StringBuilder.mStr = "0."
  append: StringBuilder.mStr = "0.234375"
  toString: StringBuilder.mStr = "0.234375"
  etc...

2. Debug build (without debugger) - stack blowout crash after a few secs:

  appendLiteral: StringBuilder.mStr = ""
  Segmentation fault: 11

3. Debug build (in gdb) - makes it further to the assert

  appendLiteral: StringBuilder.mStr = ""
  appendLiteral: StringBuilder.mStr = ""
  append: StringBuilder.mStr = ""
  append: StringBuilder.mStr = ""
  toString: StringBuilder.mStr = ""
  Assertion failure: fraction >= 0.0 && fraction <= 1.0

Again, this has only been seen on my MBP 10.8.4.

If you look at this instrumentation patch, you'll see that StringBuilder is nothing but a thin wrapper around std::string, so this is really weird.

I see moz-decimal-utils.h was added a couple of months ago, so maybe someone familiar with that could take a look?

Another possibility is that this is a compiler bug.

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

★ ~ $ /usr/bin/clang++ --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix

Comment 11

[(not currently active) Ted Mielczarek]

Can you reproduce this in one of the tinderbox-produced debug builds?
https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64-debug/

That would probably help rule out whether this is a compiler bug or not (we use a different version of clang there).

Comment 12

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: Temp mochitest to attempt to crash on try server (not a fix)

Try - https://tbpl.mozilla.org/?tree=Try&rev=cb62d035063c

Comment 13

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: Temp mochitest to attempt to crash on try server (not a fix)

Try - https://tbpl.mozilla.org/?tree=Try&rev=d488108e2aef

Comment 14

[Daniel Holbert [:dholbert]]

For future reference: it's best not to push testcases for security-sensitive bugs to the Try server.  (And especially not with a reference to the bug number, which highlights that it's for a security bug & hence is worth investigating).

There could easily be nasty folks out there with tools that scrape our Try pushes, to look for bug numbers that correspond to security bugs, and then using the results to look for possible exploit code.

When you do need a Try run for a security bug, best to use a generic/innocuous commit message in any patches, and don't include testcases if at all possible.

Comment 15

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Sorry, it occurred to me too late.

Comment 16

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

No crash on try. Same mochitest locally crashes:

 1:24.86 1985 INFO TEST-START | /tests/dom/media/tests/mochitest/test_rangeCrash.html
 1:25.31 TEST-UNEXPECTED-FAIL | /tests/dom/media/tests/mochitest/test_rangeCrash.html | Exited with code 1 during test run
 1:25.31 INFO | automation.py | Application ran for: 0:01:23.640116
 1:25.31 INFO | zombiecheck | Reading PID log: /var/folders/mf/7kfd8gkj3mlcv2_14yxmwh2r0000gn/T/tmpeZvY7Spidlog
PROCESS-CRASH | /tests/dom/media/tests/mochitest/test_rangeCrash.html | application crashed [@ libsystem_c.dylib + 0x1b01]
Crash dump filename: /var/folders/mf/7kfd8gkj3mlcv2_14yxmwh2r0000gn/T/tmpmCiYZv/minidumps/A477540E-9BAB-48D6-801E-CCEBAD1AFCEC.dmp
Operating system: Mac OS X
                  10.8.4 12E55
CPU: amd64
     family 6 model 58 stepping 9
     8 CPUs

Crash reason:  EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash address: 0x5fc00000

Thread 0 (crashed)
 0  libsystem_c.dylib + 0x1b01
    rbx = 0x00007fff5fbf6ac0   r12 = 0x0000000000039387
    r13 = 0x00000001064b7fe9   r14 = 0x000000014bd02018
    r15 = 0x000000014bd02000   rip = 0x00007fff8b562b01
    rsp = 0x00007fff5fbf6920   rbp = 0x00007fff5fbf6920
    Found by: given as instruction pointer in context
 1  libstdc++.6.dylib + 0x2e3b8
    rip = 0x00007fff918d03b9   rsp = 0x00007fff5fbf6930
    rbp = 0x00007fff5fbf6950
    Found by: stack scanning
 2  libstdc++.6.dylib + 0x2ee55
    rip = 0x00007fff918d0e56   rsp = 0x00007fff5fbf6960
    rbp = 0x00007fff5fbf6980
    Found by: stack scanning
 3  libstdc++.6.dylib + 0x2f1a6
    rip = 0x00007fff918d11a7   rsp = 0x00007fff5fbf6990
    rbp = 0x00007fff5fbf69c0
    Found by: stack scanning

Comment 17

[(not currently active) Ted Mielczarek]

Okay, so it seems likely that it's a compiler issue locally. You can download the Try build you just built (or one of those tinderbox builds I linked in comment 11) and see if that build reproduces. If not then it's not your machine, it's just your toolchain.

Comment 18

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

The tinderbox build worked locally, so it must be my toolchain. Thanks for bearing with me.