Launchpad has imported 34 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=694594.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-10-14T17:04:40+00:00 Mihai Sucan wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/0 ------------------------------------------------------------------------ On 2011-10-14T17:07:16+00:00 Mihai Sucan wrote: Created attachment 567125 gdb stacktrace 1 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). Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/1 ------------------------------------------------------------------------ On 2011-10-14T17:09:25+00:00 Mihai Sucan wrote: Created attachment 567127 gdb stacktrace 2 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! Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/2 ------------------------------------------------------------------------ On 2011-10-14T19:53:08+00:00 Jorendorff wrote: 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? Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/3 ------------------------------------------------------------------------ On 2011-10-16T14:50:56+00:00 Mihai Sucan wrote: 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! Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/4 ------------------------------------------------------------------------ On 2011-10-16T19:44:31+00:00 Mihai Sucan wrote: Bisected into the patches pushed for bug 648801. The first changeset that causes crashes is 0b6fe35629ae: https://hg.mozilla.org/mozilla-central/rev/0b6fe35629ae Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/5 ------------------------------------------------------------------------ On 2011-10-17T11:56:07+00:00 Peterv wrote: 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). Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/6 ------------------------------------------------------------------------ On 2011-10-17T12:17:52+00:00 Mihai Sucan wrote: (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! Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/7 ------------------------------------------------------------------------ On 2011-10-17T13:37:15+00:00 Peterv wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/8 ------------------------------------------------------------------------ On 2011-10-17T17:34:49+00:00 Mihai Sucan wrote: (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! Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/9 ------------------------------------------------------------------------ On 2011-10-18T17:50:07+00:00 Mihai Sucan wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/10 ------------------------------------------------------------------------ On 2011-10-19T08:58:54+00:00 Peterv wrote: CC'ing blake, he might have the same OS/compiler combo. Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/11 ------------------------------------------------------------------------ On 2011-12-06T03:15:33+00:00 Nigel Babu wrote: 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) Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/12 ------------------------------------------------------------------------ On 2012-02-08T10:06:45+00:00 Jhorak wrote: *** Bug 723900 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/13 ------------------------------------------------------------------------ On 2012-02-14T19:44:51+00:00 Chris Coulson wrote: 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 Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/20 ------------------------------------------------------------------------ On 2012-02-14T22:34:46+00:00 Chris Coulson wrote: 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? :( Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/21 ------------------------------------------------------------------------ On 2012-02-15T14:00:39+00:00 Kai Engert wrote: 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? Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/22 ------------------------------------------------------------------------ On 2012-02-15T19:22:25+00:00 Chris Coulson wrote: *** Bug 725619 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/24 ------------------------------------------------------------------------ On 2012-02-15T19:45:41+00:00 Chris Coulson wrote: Hello Kai, Yes, the problem still occurs in gcc-4.4.6 too Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/25 ------------------------------------------------------------------------ On 2012-02-16T20:28:56+00:00 Chris Coulson wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/28 ------------------------------------------------------------------------ On 2012-02-16T20:30:11+00:00 Chris Coulson wrote: Created attachment 597962 js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy() assembly with gcc-4.4 Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/29 ------------------------------------------------------------------------ On 2012-02-16T20:30:51+00:00 Chris Coulson wrote: Created attachment 597963 js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy() assembly with gcc-4.6 Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/30 ------------------------------------------------------------------------ On 2012-02-17T16:12:48+00:00 Kai Engert wrote: 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 Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/31 ------------------------------------------------------------------------ On 2012-02-20T23:14:07+00:00 Chris Coulson wrote: 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... Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/32 ------------------------------------------------------------------------ On 2012-02-22T10:52:49+00:00 Stransky wrote: 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) Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/33 ------------------------------------------------------------------------ On 2012-02-22T11:36:02+00:00 Chris Coulson wrote: Actually, that is showing that it is a weak symbol rather than a local symbol (which is what I see). Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/34 ------------------------------------------------------------------------ On 2012-02-22T11:54:21+00:00 Stransky wrote: (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. Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/35 ------------------------------------------------------------------------ On 2012-02-22T12:07:56+00:00 Chris Coulson wrote: Not quite. hidden just means that the symbol isn't exported in the public API of libxul Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/36 ------------------------------------------------------------------------ On 2012-02-22T12:14:37+00:00 Stransky wrote: 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 Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/37 ------------------------------------------------------------------------ On 2012-02-24T07:53:42+00:00 Stransky wrote: Created attachment 600326 workaround based on comment 15 Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/38 ------------------------------------------------------------------------ On 2012-02-29T12:00:18+00:00 Stransky wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/41 ------------------------------------------------------------------------ On 2012-02-29T12:03:01+00:00 Mh+mozilla wrote: (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. Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/42 ------------------------------------------------------------------------ On 2012-03-16T01:31:07+00:00 Mdinger-bugzilla wrote: 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 Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/53 ------------------------------------------------------------------------ On 2012-03-16T03:13:02+00:00 Mozilla-bugs-micahscomputing wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/931637/comments/54 ** Changed in: firefox Status: Unknown => Confirmed ** Changed in: firefox Importance: Unknown => Critical ** Bug watch added: Red Hat Bugzilla #784048 https://bugzilla.redhat.com/show_bug.cgi?id=784048 ** Bug watch added: GCC Bugzilla #52430 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52430 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/931637 Title: Firefox 10.0.1 crashes when trying to enter a command on the Web Console Status in The Mozilla Firefox Browser: Confirmed Status in “firefox” package in Ubuntu: Confirmed Status in “gcc-4.4” package in Ubuntu: Fix Released Status in “firefox” source package in Lucid: Fix Released Status in “gcc-4.4” source package in Lucid: Fix Released Status in “firefox” source package in Maverick: Fix Released Status in “gcc-4.4” source package in Maverick: Fix Released Status in “firefox” source package in Natty: Invalid Status in “gcc-4.4” source package in Natty: Invalid Status in “firefox” source package in Oneiric: Invalid Status in “gcc-4.4” source package in Oneiric: New Bug description: Bug first appeared last week after updating to Firefox 10 using Synaptic. Original symptom was crashing Firefox when navigating a site I'm developing (which logs a lot to console in development environment). Further discovery indicated that I could crash Firefox by clicking on the DOM tab in Firebug. At that point, I re-installed Firefox, created a new profile, re-installed Firebug and could still reproduce the crash. I created a new user on my system, repeated the prior steps, same result. After some searching, I found these discussions: http://groups.google.com/group/firebug/browse_thread/thread/bfb5a8b038ef2328/65171984c28775a1?show_docid=65171984c28775a1# https://bugzilla.mozilla.org/show_bug.cgi?id=725619 At which point, I tried simply opening the Web Console and typing print, which would crash the browser before finishing typing the command, even with a clean install and no plug-ins. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: firefox 10.0.1+build1-0ubuntu0.10.04.1 ProcVersionSignature: Ubuntu 2.6.32-38.83-generic 2.6.32.52+drm33.21 Uname: Linux 2.6.32-38-generic x86_64 NonfreeKernelModules: nvidia AddonCompatCheckDisabled: False AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21. AplayDevices: **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: HDA Generic [HDA Generic] Subdevices: 1/1 Subdevice #0: subdevice #0 Architecture: amd64 ArecordDevices: **** List of CAPTURE Hardware Devices **** card 0: Intel [HDA Intel], device 0: HDA Generic [HDA Generic] Subdevices: 1/1 Subdevice #0: subdevice #0 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: bjorn2 19882 F.... pulseaudio BuildID: 20120209215013 CRDA: Error: [Errno 2] No such file or directory Card0.Amixer.info: Card hw:0 'Intel'/'HDA Intel at 0xf2620000 irq 17' Mixer name : 'Conexant ID 5069' Components : 'HDA:14f15069,17aa218b,00100302' Controls : 6 Simple ctrls : 4 Card1.Amixer.info: Card hw:1 'NVidia'/'HDA NVidia at 0xcdefc000 irq 16' Mixer name : 'Nvidia ID a' Components : 'HDA:10de000a,10de0101,00100100' Controls : 0 Simple ctrls : 0 Card1.Amixer.values: Card29.Amixer.info: Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw 6MHT39WW-1.14' Mixer name : 'ThinkPad EC 6MHT39WW-1.14' Components : '' Controls : 1 Simple ctrls : 1 Card29.Amixer.values: Simple mixer control 'Console',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Channel: release Date: Mon Feb 13 13:31:40 2012 EtcFirefoxSyspref: Cannot parse /etc/firefox/syspref.js - [Errno 2] No such file or directory: '/etc/firefox/syspref.js' ForcedLayersAccel: False InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) IpRoute: 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.38 default via 192.168.100.254 dev eth0 Plugins: Shockwave Flash - Lib=libflashplayer.so, Location=/usr/lib/firefox-addons/plugins ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash Profiles: Profile0 (Default) - LastVersion=10.0.1/20120209215013 (Running) RunningIncompatibleAddons: False SourcePackage: firefox dmi.bios.date: 07/14/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 6NET64WW (1.27 ) dmi.board.name: 4318CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr6NET64WW(1.27):bd07/14/2010:svnLENOVO:pn4318CTO:pvrThinkPadW510:rvnLENOVO:rn4318CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 4318CTO dmi.product.version: ThinkPad W510 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/931637/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
