694594 - Crashes with gcc 4.4.3

Reporter

Description

•

13 years ago

I get semi-random crashes while running the Firefox developer tools mochitests on my machine.

This started happening since I pulled https://tbpl.mozilla.org/?tree=Fx-Team&rev=9d697ecaf161 ... and it still happens, even with the latest fx-team code.

Tests from the Style Inspector, Source Editor and from the Web Console cause crashes, in opt and dbg builds.

I am not sure if the component I picked is correct, I just saw the crasher is related to js/Vector.h and jscntxt.h, etc.

Going to attach gdb stacktraces.

Mihai Sucan [:msucan]

Reporter

Comment 1

•

13 years ago

Attached file gdb stacktrace 1 — Details

Generated debug output and stacktrace as suggested in:
https://wiki.ubuntu.com/MozillaTeam/Bugs

This is the result of running the mochitest-browser-chrome tests from browser/devtools (all our tests).

Mihai Sucan [:msucan]

Reporter

Comment 2

•

13 years ago

Attached file gdb stacktrace 2 — Details

Another stacktrace.

I would really appreciate a fix for this crash ... it breaks daily work on my machine. Please let me know if further information is needed. Thank you!

Jason Orendorff [:jorendorff]

Comment 3

•

13 years ago

Both stacks are assertion failures in Vector.

msucan says you can trigger this like so:

  - build with --enable-debug on Linux x86-64
  - start the browser
  - open the console (Ctrl+Shift+K)
  - type w

The console's auto-complete feature triggers the assertion.

gkw, could you please reproduce this and bisect if possible?

Mihai Sucan [:msucan]

Reporter

Comment 4

•

13 years ago

This crasher started since bug 648801 landed.

Peter, can you please look into this? I haven't seen anyone who can repro the crasher. I can't even repro the crasher with tinderbox builds. This happens only on my own local builds.

if I set pref("dom.new_bindings", false) I still get the crash.

I have Ubuntu 10.04 LTS (amd64), gcc 4.4.3 (from official repos), everything up-to-date. Please let me know if you need any additional technical info about my build setup.


Thank you!

Blocks: 648801

Severity: major → critical

Mihai Sucan [:msucan]

Reporter

Comment 5

•

13 years ago

Bisected into the patches pushed for bug 648801. The first changeset that causes crashes is 0b6fe35629ae:

https://hg.mozilla.org/mozilla-central/rev/0b6fe35629ae

Peter Van der Beken [:peterv]

Comment 6

•

13 years ago

I can't reproduce this on Ubuntu 11.04 (tried running the tests and using autocomplete in the console).

(In reply to Mihai Sucan [:msucan] from comment #5)
> Bisected into the patches pushed for bug 648801. The first changeset that
> causes crashes is 0b6fe35629ae:
> 
> https://hg.mozilla.org/mozilla-central/rev/0b6fe35629ae

That'd be very surprising, that changeset adds code that isn't actually used (later patches cause it to be used).

Mihai Sucan [:msucan]

Reporter

Comment 7

•

13 years ago

(In reply to Peter Van der Beken [:peterv] from comment #6)
> I can't reproduce this on Ubuntu 11.04 (tried running the tests and using
> autocomplete in the console).

Even nightly builds I get from mozilla.org work fine. It's certainly a problem (only?) on my machine. Only my local builds crash...


> (In reply to Mihai Sucan [:msucan] from comment #5)
> > Bisected into the patches pushed for bug 648801. The first changeset that
> > causes crashes is 0b6fe35629ae:
> > 
> > https://hg.mozilla.org/mozilla-central/rev/0b6fe35629ae
> 
> That'd be very surprising, that changeset adds code that isn't actually used
> (later patches cause it to be used).

Heh, surprising indeed. Unfortunately, that's what I found yesterday...


Are you on IRC, by any chance? I can try things live, as you see fit.

Anything I can help with debugging this crasher? Are the gdb stack traces of any help?

Thank you!

Peter Van der Beken [:peterv]

Comment 8

•

13 years ago

The gdb traces are in JS engine code that's unrelated to that changeset. Are you saying that without that changeset you can't reproduce at all and with it you can 100% of the time? If so, can you try removing just the change in qsgen.py from that changeset?
If that's the changeset that causes it this looks more like a compiler bug.

Mihai Sucan [:msucan]

Reporter

Comment 9

•

13 years ago

(In reply to Peter Van der Beken [:peterv] from comment #8)
> The gdb traces are in JS engine code that's unrelated to that changeset. Are
> you saying that without that changeset you can't reproduce at all and with
> it you can 100% of the time? If so, can you try removing just the change in
> qsgen.py from that changeset?
> If that's the changeset that causes it this looks more like a compiler bug.

If I take out the qsgen.py change I get no crash. I can always reproduce this.

Can you please try with Ubuntu 10.04 on your machine? Compile Firefox and run the tests. Please make sure the OS is up-to-date (gcc 4.4.3).

Thank you!

Mihai Sucan [:msucan]

Reporter

Comment 10

•

13 years ago

Downloaded the latest clang and llvm sources, built them, then built the latest Firefox from fx-team. No crashes.

It looks like, yes, we can blame gcc 4.4.3 having a bug.

Summary: Crashes while running the developer tools tests → Crashes with gcc 4.4.3

Peter Van der Beken [:peterv]

Comment 11

•

13 years ago

CC'ing blake, he might have the same OS/compiler combo.

Nigel Babu [:nigelb]

Comment 12

•

13 years ago

Hi, I have the same OS/compiler combo and started faced this crash from a few days ago (I was working with an older tree and then updated)

Chris Coulson

Comment 14

•

12 years ago

On a build with gcc 4.4.3 (with --disable-jemalloc --enable-valgrind), I see these quite consistently in valgrind after typing in the Web Console:

==1460== Invalid write of size 8
==1460==    at 0x8B3349E: js::CrossCompartmentWrapper::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (jscntxt.h:2220)
==1460==    by 0x8ADEBF4: js::Proxy::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (jsproxy.cpp:860)
==1460==    by 0x8AA4971: js::GetIterator(JSContext*, JSObject*, unsigned int, JS::Value*) (jsiter.cpp:655)
==1460==    by 0x8AA4D1C: js_ValueToIterator(JSContext*, unsigned int, JS::Value*) (jsiter.cpp:789)
==1460==    by 0x8A9282C: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:2465)
==1460==    by 0x8A8F33B: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jsinterp.cpp:647)
==1460==    by 0x8A5E244: js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A8F1B6: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:297)
==1460==    by 0x8A8F8C5: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A16B9B: JS_CallFunctionValue (jsapi.cpp:5199)
==1460==    by 0x851673F: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJSClass.cpp:1530)
==1460==    by 0x851140E: nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJS.cpp:611)
==1460==  Address 0x1ead2338 is 0 bytes after a block of size 8 alloc'd
==1460==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==1460==    by 0x857D3D5: js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy(unsigned long) (Utility.h:166)
==1460==    by 0x8B335A2: js::CrossCompartmentWrapper::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (Vector.h:675)
==1460==    by 0x8ADEBF4: js::Proxy::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (jsproxy.cpp:860)
==1460==    by 0x8AA4971: js::GetIterator(JSContext*, JSObject*, unsigned int, JS::Value*) (jsiter.cpp:655)
==1460==    by 0x8AA4D1C: js_ValueToIterator(JSContext*, unsigned int, JS::Value*) (jsiter.cpp:789)
==1460==    by 0x8A9282C: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:2465)
==1460==    by 0x8A8F33B: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jsinterp.cpp:647)
==1460==    by 0x8A5E244: js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A8F1B6: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:297)
==1460==    by 0x8A8F8C5: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A16B9B: JS_CallFunctionValue (jsapi.cpp:5199)
==1460== 
==1460== Invalid write of size 8
==1460==    at 0x8B334B0: js::CrossCompartmentWrapper::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (jscntxt.h:2220)
==1460==    by 0x8ADEBF4: js::Proxy::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (jsproxy.cpp:860)
==1460==    by 0x8AA4971: js::GetIterator(JSContext*, JSObject*, unsigned int, JS::Value*) (jsiter.cpp:655)
==1460==    by 0x8AA4D1C: js_ValueToIterator(JSContext*, unsigned int, JS::Value*) (jsiter.cpp:789)
==1460==    by 0x8A9282C: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:2465)
==1460==    by 0x8A8F33B: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jsinterp.cpp:647)
==1460==    by 0x8A5E244: js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A8F1B6: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:297)
==1460==    by 0x8A8F8C5: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A16B9B: JS_CallFunctionValue (jsapi.cpp:5199)
==1460==    by 0x851673F: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJSClass.cpp:1530)
==1460==    by 0x851140E: nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJS.cpp:611)
==1460==  Address 0x1ead28c0 is not stack'd, malloc'd or (recently) free'd
==1460== 
==1460== Invalid write of size 8
==1460==    at 0x8B334FC: js::CrossCompartmentWrapper::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (jswrapper.cpp:679)
==1460==    by 0x8ADEBF4: js::Proxy::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (jsproxy.cpp:860)
==1460==    by 0x8AA4971: js::GetIterator(JSContext*, JSObject*, unsigned int, JS::Value*) (jsiter.cpp:655)
==1460==    by 0x8AA4D1C: js_ValueToIterator(JSContext*, unsigned int, JS::Value*) (jsiter.cpp:789)
==1460==    by 0x8A9282C: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:2465)
==1460==    by 0x8A8F33B: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jsinterp.cpp:647)
==1460==    by 0x8A5E244: js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A8F1B6: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:297)
==1460==    by 0x8A8F8C5: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A16B9B: JS_CallFunctionValue (jsapi.cpp:5199)
==1460==    by 0x851673F: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJSClass.cpp:1530)
==1460==    by 0x851140E: nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJS.cpp:611)
==1460==  Address 0x1ead2338 is 0 bytes after a block of size 8 alloc'd
==1460==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==1460==    by 0x857D3D5: js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy(unsigned long) (Utility.h:166)
==1460==    by 0x8B335A2: js::CrossCompartmentWrapper::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (Vector.h:675)
==1460==    by 0x8ADEBF4: js::Proxy::iterate(JSContext*, JSObject*, unsigned int, JS::Value*) (jsproxy.cpp:860)
==1460==    by 0x8AA4971: js::GetIterator(JSContext*, JSObject*, unsigned int, JS::Value*) (jsiter.cpp:655)
==1460==    by 0x8AA4D1C: js_ValueToIterator(JSContext*, unsigned int, JS::Value*) (jsiter.cpp:789)
==1460==    by 0x8A9282C: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:2465)
==1460==    by 0x8A8F33B: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jsinterp.cpp:647)
==1460==    by 0x8A5E244: js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A8F1B6: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:297)
==1460==    by 0x8A8F8C5: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:148)
==1460==    by 0x8A16B9B: JS_CallFunctionValue (jsapi.cpp:5199)

And this in a debug build, I get this before it crashes too:

Assertion failure: mLength + incr <= mCapacity, at ./../../dist/include/js/Vector.h:678

Chris Coulson

Comment 15

•

12 years ago

Uninlining js::Vector<T,N,AP>::calculateNewCapacity() makes the problem go away, but how come we've only started seeing this issue in Firefox 10? :(

Kai Engert (:KaiE:)

Comment 16

•

12 years ago

Would you be able to locally build a gcc-4.4.6, and rebuild Firefox with 4.4.6, to see if the bug has already been fixed on the gcc 4.4.x branch?

Chris Coulson

Comment 18

•

12 years ago

Hello Kai,

Yes, the problem still occurs in gcc-4.4.6 too

Chris Coulson

Comment 19

•

12 years ago

I did some more debugging of this this morning, and here is a summary of what I found:

- js::Vector<long, 8ul, js::TempAllocPolicy>::calculateNewCapacity() doesn't actually appear to be inlined by the compiler in both the working / non-working cases.

- Using JS_NEVER_INLINE for js::Vector<T,N,AP>::calculateNewCapacity() makes the problem go away.

- In the non-working case with gcc-4.4, js::Vector<long, 8ul, js::TempAllocPolicy>::calculateNewCapacity() appears to be completely optimized for the append() case (ie, it completely ignores lengthInc, and just assumes this is always 1). This can be seen by looking at the generated code:

0000000000da3b9a <js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy(unsigned long)>:
  da3b9a:    41 54                    push   %r12
  da3b9c:    48 8d 47 20              lea    0x20(%rdi),%rax
  da3ba0:    55                       push   %rbp
  da3ba1:    53                       push   %rbx
  da3ba2:    48 89 fb                 mov    %rdi,%rbx
  da3ba5:    48 83 ec 10              sub    $0x10,%rsp
  da3ba9:    48 39 47 08              cmp    %rax,0x8(%rdi)

Up until here, %rdi contains our instance pointer, and %rsi contains "incr". 0x8(%rdi) is the pointer to "mBegin" and 0x20(%rdi) is "storage". The last instruction is usingInlineStorage().

  da3bad:    48 8b 77 10              mov    0x10(%rdi),%rsi

Y'ouch. This overwrites "incr" with "mLength", which then gets passed to calculateNewCapacity() here:

  da3bb1:    48 8d 54 24 08           lea    0x8(%rsp),%rdx
  da3bb6:    75 68                    jne    da3c20 <js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy(unsigned long)+0x86>
  da3bb8:    e8 85 ff ff ff           callq  da3b42 <T.2961>

%rdx now contains the address of where calculateNewCapacity() will store "newCap"

I'm not sure what this is doing, but it seems to pretty much boil down to "move 0x1 to (%rdx):

0000000000da3b42 <T.2961>:
  da3b42:    48 89 f0                 mov    %rsi,%rax
  da3b45:    48 83 ec 08              sub    $0x8,%rsp
  da3b49:    48 83 c0 01              add    $0x1,%rax
  da3b4d:    72 42                    jb     da3b91 <T.2961+0x4f>
  da3b4f:    48 b9 00 00 00 00 00     movabs $0xf000000000000000,%rcx
  da3b56:    00 00 f0
  da3b59:    48 85 c8                 test   %rcx,%rax
  da3b5c:    75 33                    jne    da3b91 <T.2961+0x4f>
  da3b5e:    48 83 f8 01              cmp    $0x1,%rax
  da3b62:    41 b8 01 00 00 00        mov    $0x1,%r8d
  da3b68:    76 13                    jbe    da3b7d <T.2961+0x3b>
  da3b6a:    48 0f bd f6              bsr    %rsi,%rsi
  da3b6e:    b9 3f 00 00 00           mov    $0x3f,%ecx
  da3b73:    83 f6 3f                 xor    $0x3f,%esi
  da3b76:    29 f1                    sub    %esi,%ecx
  da3b78:    ff c1                    inc    %ecx
  da3b7a:    49 d3 e0                 shl    %cl,%r8
  da3b7d:    4c 89 02                 mov    %r8,(%rdx)
  da3b80:    48 ba 00 00 00 00 00     movabs $0xf000000000000000,%rdx
  da3b87:    00 00 f0
  da3b8a:    b0 01                    mov    $0x1,%al
  da3b8c:    49 85 d0                 test   %rdx,%r8
  da3b8f:    74 07                    je     da3b98 <T.2961+0x56>
  da3b91:    e8 aa 01 87 ff           callq  613d40 <js::TempAllocPolicy::reportAllocOverflow() const@plt>
  da3b96:    31 c0                    xor    %eax,%eax
  da3b98:    5a                       pop    %rdx
  da3b99:    c3                       retq

Now, we call malloc with 0x1 * 8:

  da3bbd:    84 c0                    test   %al,%al
  da3bbf:    0f 84 a0 00 00 00        je     da3c65 <js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy(unsigned long)+0xcb>
  da3bc5:    48 8b 6c 24 08           mov    0x8(%rsp),%rbp
  da3bca:    48 c1 e5 03              shl    $0x3,%rbp
  da3bce:    48 89 ef                 mov    %rbp,%rdi
  da3bd1:    e8 aa 6f 87 ff           callq  61ab80 <malloc@plt>

And so, growStorageBy() appears to succeed, yet it has allocated a lot less than the caller thinks. mLength gets incremented by the value of "incr", and then MakeRangeGCSafe() (from js::AutoVectorRooter<long>::growBy()) tramples all over the end of the buffer.

Chris Coulson

Comment 20

•

12 years ago

Attached file js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy() assembly with gcc-4.4 — Details

Chris Coulson

Comment 21

•

12 years ago

Attached file js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy() assembly with gcc-4.6 — Details

Kai Engert (:KaiE:)

Comment 22

•

12 years ago

If you were able to come up with a minimal testcase, you could report it as a bug at http://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc

Matt

Updated

•

12 years ago

Keywords: crash, reproducible

Chris Coulson

Comment 23

•

12 years ago

I'm not convinced this is a compiler bug at all now. The implementation of js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy(unsigned long) in jswrapper.o looks correct, and is actually perfectly ok. The issue is that another implementation of this is getting linked in to the final .so instead (from js/xpconnect/src/dombindings.o, which is also using js::AutoIdVector - see dombindings.cpp). This implementation is optimized differently because it only uses js::AutoIdVector::append(), which explains my finding in comment 19.

This also explains comment 5.

I imagine that it's just pure luck that this works with newer gcc versions...

Martin Stránský [:stransky] (ni? me)

Comment 24

•

12 years ago

Actually it may be a gcc bug after all, because the growStorageBy() from dombindings.cpp are hidden/local so they should not be linked to final .so:

$objdump -t dombindings.o | grep growStorageBy | c++filt
0000000000000000 l    d  .text._ZN2js6VectorI4jsidLm8ENS_15TempAllocPolicyEE13growStorageByEm	0000000000000000 .text._ZN2js6VectorI4jsidLm8ENS_15TempAllocPolicyEE13growStorageByEm

0000000000000000  w    F .text._ZN2js6VectorI4jsidLm8ENS_15TempAllocPolicyEE13growStorageByEm	00000000000001d1 .hidden js::Vector<jsid, 8ul, js::TempAllocPolicy>::growStorageBy(unsigned long)

Chris Coulson

Comment 25

•

12 years ago

Actually, that is showing that it is a weak symbol rather than a local symbol (which is what I see).

Martin Stránský [:stransky] (ni? me)

Comment 26

•

12 years ago

(In reply to Chris Coulson from comment #25)
> Actually, that is showing that it is a weak symbol rather than a local
> symbol (which is what I see).

Yeah, but the weak symbol is .hidden so it should be ignored by linker.

Chris Coulson

Comment 27

•

12 years ago

Not quite. hidden just means that the symbol isn't exported in the public API of libxul

Martin Stránský [:stransky] (ni? me)

Comment 28

•

12 years ago

Yeah. BTW. with gcc-4.4.x, the js::Vector<jsid, 8ul, js::TempAllocPolicy>::growStorageBy(unsigned long) is linked in libxul.so (RHEL6)

$ objdump -t libxul.so | grep _ZN2js6VectorI4jsidLm8ENS_15TempAllocPolicyEE13growStorageByEm

0000000001094d9a l     F .text	00000000000001d1
js::Vector<jsid, 8ul, js::TempAllocPolicy>::growStorageBy(unsigned long)

but with gcc 4.6.1 it's completely optimized away (Fedora15):

$ objdump -t /usr/lib64/xulrunner-2/libxul.so | grep _ZN2js6VectorI4jsidLm8ENS_15TempAllocPolicyEE13growStorageByEm

Martin Stránský [:stransky] (ni? me)

Comment 29

•

12 years ago

Attached patch workaround based on comment 15 — Details — Splinter Review

Martin Stránský [:stransky] (ni? me)

Comment 30

•

12 years ago

Confirmed as a gcc 4.4 bug:

http://gcc.gnu.org/PR52430
https://bugzilla.redhat.com/show_bug.cgi?id=784048#c9

the latter contains a workaround.

Mike Hommey [:glandium]

Comment 31

•

12 years ago

 (In reply to Martin Stránský from comment #30)
> Confirmed as a gcc 4.4 bug:
> 
> http://gcc.gnu.org/PR52430
> https://bugzilla.redhat.com/show_bug.cgi?id=784048#c9
> 
> the latter contains a workaround.

You are not authorized to access bug #784048. To see this bug, you must first log in to an account with the appropriate permissions.

Matt

Comment 32

•

12 years ago

Gcc states this is fixed for 4.4.7 and launchpad also states fixed because of gcc's fix but I still see the crash with firefox 11 in ubuntu.  Is anyone else still seeing this?  I expected it would be fixed with the gcc fix.

See bug 725619 for context regarding ubuntu and this crash.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52430
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/931637

Micah Gersten

Comment 33

•

12 years ago

Which version of Firefox 11 on Ubuntu are you seeing this with?  We've already had a report of someone experiencing a crash that's now fixed.

Launchpad

Updated

•

12 years ago

See Also: → https://launchpad.net/bugs/931637

Matt

Comment 34

•

12 years ago

Yes but apparently it is not fixed for everyone.  Oddly, I see the crash on all web pages ("www.google.com") except some built in pages such as "about:crashes".

I did successfully build a standard firefox build from hg tip locally and it did not crash.  I used gcc 4.4.4-14ubuntu5.1 which had the gcc fix included so I am not sure why the mozillateam build does not work properly.

I was going to check further but my computer overheats when compiling so I will leave it as is.

Firefox 11
Ubuntu 10.10 
mozillateam
firefox-stable

Dave Hylands [:dhylands]

Assignee

Comment 35

•

12 years ago

I'm seeing the same problem with the 4.4.3 ARM compiler. I only see the problem in debug builds. I'm seeing the problem in B2G, and its 100% reproducible.

The following JavaScript triggers the JS_ASSERT(mLength <= mReserved); in the Vector<T,N,AP>::reserve(size_t request) function.

<pre>
28:  function getSdkVersion() {
29:    Cu.import("resource://gre/modules/ctypes.jsm");
30:    try {
31:      let cutils = ctypes.open("libcutils.so");
32:      let cbuf = ctypes.char.array(4096)();
33:      let c_property_get = cutils.declare("property_get", ctypes.default_abi,
34:                                          ctypes.int,       // return value: length
35:                                          ctypes.char.ptr,  // key
36:                                          ctypes.char.ptr,  // value
37:                                          ctypes.char.ptr); // default
38:      let property_get = function (key, defaultValue) {
39:        if (defaultValue === undefined) {
40:          defaultValue = null;
41:        }
42:        c_property_get(key, cbuf, defaultValue);
43:        return cbuf.readString();
44:      }
45:      return parseInt(property_get("ro.build.version.sdk"));
46:    } catch(e) {
47:      // Eat it.  Hopefully we're on a non-Gonk system ...
48:      // 
49:      // XXX we should check that
50:      return 0;
51:    }
52:  }
</pre>

and the JSStack looks like:

<pre>
(gdb) call DumpJSStack()
0 getSdkVersion() ["jar:file:///system/b2g/omni.ja!/components/WifiWorker.js":37]
    this = undefined
1 anonymous() ["jar:file:///system/b2g/omni.ja!/components/WifiWorker.js":54]
    this = undefined
2 <TOP LEVEL> ["jar:file:///system/b2g/omni.ja!/components/WifiWorker.js":27]
    this = [object BackstagePass @ 0x41b11200 (native @ 0x40a62fc4)]
</pre>

Dave Hylands [:dhylands]

Assignee

Comment 36

•

12 years ago

Attached patch Workaround which only affects DEBUG builds (obsolete) — Details — Splinter Review

This is a slightly different workaround which only affects DEBUG builds.

Dave Hylands [:dhylands]

Assignee

Updated

•

12 years ago

Attachment #632053 - Flags: review?(luke)

Luke Wagner [:luke]

Comment 37

•

12 years ago

Comment on attachment 632053 [details] [diff] [review]
Workaround which only affects DEBUG builds

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

::: js/public/Vector.h
@@ +565,5 @@
>  STATIC_POSTCONDITION(!return || newCap >= curLength + lengthInc)
> +#ifdef DEBUG
> +// By making this method not inline for debug builds, it sidesteps
> +// the compiler generating incorrect code. See bug 694594.
> +JS_NEVER_INLINE bool

Surrounding comments use /* */.  Also, I think you could say, more succinctly:

/* ARM compiler bug workaround, see bug 694594. */

Attachment #632053 - Flags: review?(luke) → review+

Dave Hylands [:dhylands]

Assignee

Comment 38

•

12 years ago

Attached patch Workaround which only affects DEBUG builds v2 — Details — Splinter Review

Redid comment. The problem actually affects both ARM and x86

Dave Hylands [:dhylands]

Assignee

Updated

•

12 years ago

Attachment #632053 - Attachment is obsolete: true

Dave Hylands [:dhylands]

Assignee

Updated

•

12 years ago

Attachment #632144 - Flags: review+

Dave Hylands [:dhylands]

Assignee

Updated

•

12 years ago

Keywords: checkin-needed

Ryan VanderMeulen [:RyanVM]

Comment 39

•

12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/b9cf42e0e76d

Assignee: general → dhylands

Flags: in-testsuite-

Keywords: checkin-needed

Target Milestone: --- → mozilla16

Ed Morley [:emorley]

Comment 40

•

12 years ago

https://hg.mozilla.org/mozilla-central/rev/b9cf42e0e76d

Status: NEW → RESOLVED

Closed: 12 years ago

Resolution: --- → FIXED

gdb stacktrace 1 13 years ago Mihai Sucan [:msucan] 376.79 KB, text/plain		Details
gdb stacktrace 2 13 years ago Mihai Sucan [:msucan] 229.44 KB, text/plain		Details
js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy() assembly with gcc-4.4 12 years ago Chris Coulson 5.70 KB, text/plain		Details
js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy() assembly with gcc-4.6 12 years ago Chris Coulson 6.55 KB, text/plain		Details
workaround based on comment 15 12 years ago Martin Stránský [:stransky] (ni? me) 734 bytes, patch		Details \| Diff \| Splinter Review
Workaround which only affects DEBUG builds 12 years ago Dave Hylands [:dhylands] 939 bytes, patch	luke : review+	Details \| Diff \| Splinter Review
Workaround which only affects DEBUG builds v2 12 years ago Dave Hylands [:dhylands] 871 bytes, patch	dhylands : review+	Details \| Diff \| Splinter Review