Firefox 10.0.1 crashes when trying to enter a command on the Web Console

Bug #931637 reported by Bjorn Christianson on 2012-02-13
138
This bug affects 25 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Critical
firefox (Ubuntu)
Undecided
Unassigned
Lucid
Undecided
Unassigned
Maverick
Undecided
Unassigned
gcc-4.4 (Ubuntu)
Undecided
Unassigned
Lucid
Undecided
Unassigned
Maverick
Undecided
Unassigned

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

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.

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).

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!

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?

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!

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

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

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).

(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!

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.

(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!

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.

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

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)

*** Bug 723900 has been marked as a duplicate of this bug. ***

Bjorn Christianson (bjorn-k4) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed

This bug affects only Ubuntu build (both 10 and 10.0.1). Works OK in official build (both ESR and "standard" releases).

Shrenik (shrenik-bhura) wrote :

I don't think this is only triggered by firebug. Clicking on Firebug's DOM tab is a sure crasher.

Even with firebug disabled, for e.g. other addons such as Awesome Screeshot from Diigo. Take a screenshot -> click Done -> Close Tab and the browser crashes.

Everytime I am closing the browser, it crashes and notifies to submit a bug report:

Here are some that have been uploaded already -

http://crash-stats.mozilla.com/report/index/bp-6ff8f906-cb26-4864-82ed-31db72120213
http://crash-stats.mozilla.com/report/index/bp-5a9ac084-5c83-42e9-9295-923132120213

Am moving to official build till we see some solution to this as FF is unsuable on Ubuntu as of now.

joe (relisys002) wrote :

This is definitely not limited to Firebug. To reproduce:

Open the Web Console (Ctrl + Shift + K)
Start typing anything
Watch Firefox crash

It only seems to be a problem with the 64 bit Ubuntu and Mozillateam builds, the build straight from Mozilla is unaffected. Based on my experience and the comments from https://bugzilla.mozilla.org/show_bug.cgi?id=725619 this seems limited to the 64 bit build running on Ubuntu 10.04, but it's possible that 32 bit users on other version of Ubuntu simply haven't reported in.

I was using the Next repo for a while before 11 was stable and this problem cropped up some time before the new year, maybe that'll help you track down the bug. I've tried running the mozregression tool but can't reproduce the problem in any versions with that since it's not a problem in the builds (even nightlies) coming from Mozilla directly.

Like the post above me, I've moved to the official build as the builds from Ubuntu and Mozillateam are completely unusable for anyone doing web development.

Download full text (7.2 KiB)

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)...

Read more...

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? :(

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?

pdescham49 (pdescham49) wrote :

This is Totally reproducible in Ubuntu 11.04 as well.

Uninstalled FB
removed my .mozilla profile folder
restarted FireFox
Web Console (Ctrl + Shift + K)

typed in "Print" got to "pri" crash. Dump submitted with this url posted in it's contents:

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/931637?comments=all

Feel free to contact I work in FF every day.

FF 10
Ubuntu 11.04 64 bit

I can also reproduce via the Web Console (Ctrl + Shift + K)

*** Bug 725619 has been marked as a duplicate of this bug. ***

Hello Kai,

Yes, the problem still occurs in gcc-4.4.6 too

Bjorn Christianson (bjorn-k4) wrote :

Note that the bugzilla.org bug

https://bugzilla.mozilla.org/show_bug.cgi?id=725619

was marked a duplicate of this bug

https://bugzilla.mozilla.org/show_bug.cgi?id=694594

which indicates that the problem's root is compiling Firefox 10+ with gcc 4.4.3+. I've little experience with building packages, but it seems a simple fix for the Ubuntu distributions would be to compile with gcc <4.4.3.

Firefox running on Ubuntu 10.10 also affected by this bug.

Download full text (4.1 KiB)

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>
...

Read more...

Created attachment 597962
js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy() assembly with gcc-4.4

Created attachment 597963
js::Vector<long, 8ul, js::TempAllocPolicy>::growStorageBy() assembly with gcc-4.6

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

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...

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)

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

(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.

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

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

Created attachment 600326
workaround based on comment 15

This bug is not limited to Firebug. It concerns Zotero, too: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/940776

Xavier Robin (jti-533g) wrote :

I can reproduce this crash nearly each time I save a reference from the address bar with Zotero.
I have a bunch of Firefox crash reports if needed.

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.

 (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.

Tom (tom-lorinthe) wrote :

Same for me: Ubuntu 10.10 / FF10 - 100% crash on Firebug, Web Console and others.

Matthias Klose (doko) on 2012-03-08
Changed in firefox (Ubuntu Natty):
status: New → Invalid
Changed in firefox (Ubuntu Oneiric):
status: New → Invalid
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-4.4 - 4.4.6-15ubuntu1

---------------
gcc-4.4 (4.4.6-15ubuntu1) precise; urgency=low

  * Merge with Debian.

gcc-4.4 (4.4.6-15) unstable; urgency=low

  * Update to SVN 20120308 from the gcc-4_4-branch (r185107).
    - Fix PR tree-optimization/52430 (LP: #931637), PR target/52408 (hppa),
      PR target/51408, PR target/51393 (x86 avx), PR c++/51344.
  * gdc-4.4: Provide <gnu-triplet>-{gdc,gdmd}-4.4 symlinks.

gcc-4.4 (4.4.6-14) unstable; urgency=low

  * Fix passing the dynamic linker on armel.
 -- Matthias Klose <email address hidden> Thu, 08 Mar 2012 20:02:02 +0100

Changed in gcc-4.4 (Ubuntu):
status: New → Fix Released
Matthias Klose (doko) wrote :

packages for lucid and maverick building in the ubuntu-toolchain-r/glibc ppa. binaries can be copied after checking the test-summary for regressions.

Changed in gcc-4.4 (Ubuntu Natty):
status: New → Invalid
mmalmeida (mmalmeida) wrote :

Matthias Klose: does that mean packages will be added to the updates in lucid/maverick?

I've just confirmed the presence of this bug in Maverick with Firefox 10.0.2-ubuntu.

1) Start firefox
2) Open the console tab in firebug
3) write "self"
4) Firefox crashes.

I've tested with a clean Firefox 10.0.2 version from Mozilla's website and the problem isn't there, which means this is definitely an issue with Ubuntu's Firefox version.

Chris Coulson (chrisccoulson) wrote :

It will be fixed in the next update

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-4.4 - 4.4.3-4ubuntu5.1

---------------
gcc-4.4 (4.4.3-4ubuntu5.1) lucid; urgency=low

  * Fix PR tree-optimization/52430, taken from the 4.4 branch. LP: #931637.
 -- Matthias Klose <email address hidden> Thu, 08 Mar 2012 20:34:00 +0100

Changed in gcc-4.4 (Ubuntu Lucid):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-4.4 - 4.4.4-14ubuntu5.1

---------------
gcc-4.4 (4.4.4-14ubuntu5.1) maverick; urgency=low

  * Fix PR tree-optimization/52430, taken from the 4.4 branch. LP: #931637.
 -- Matthias Klose <email address hidden> Thu, 08 Mar 2012 20:44:24 +0100

Changed in gcc-4.4 (Ubuntu Maverick):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (4.4 KiB)

This bug was fixed in the package firefox - 11.0+build1-0ubuntu0.10.04.2

---------------
firefox (11.0+build1-0ubuntu0.10.04.2) lucid; urgency=low

  * New upstream stable release (FIREFOX_11_0_BUILD1)
    - see LP: #951250 for USN information

  * Rebuilt against updated gcc to fix LP: #931637
  * Ensure that the crash reporter is disabled if rebuilt by Ubuntu
    derivatives, as there will be no crash symbols for those
    - update debian/rules
  * Only add "Ubuntu" to the UA string when being built for Ubuntu
    - update debian/rules
  * Temporarily disable ipdl tests due to build failures. These aren't
    enabled upstream, anyway
    - update debian/config/mozconfig.in
  * Always set the update channel - not setting it at build-time on release
    builds breaks the extensions.checkCompatibility pref. The only things
    using it at runtime are nsBlocklistService, Test Pilot (beta + aurora)
    and the about dialog (where the channel is hidden anyway)
    - update debian/rules
    - update debian/firefox.install.in
  * Fix LP: #898883 - IPC xpcshell tests hang the buildd's. Give all
    xpcshell tests an X display, as plugin-container won't work without one
    - update debian/build/testsuite.mk
  * Turn on all IPC xpcshell tests again
    - update debian/build/testsute.mk
  * Drop the default-apps xml file - there is already one provided by
    gnome-control-center, so ours duplicates this. We never used to install
    it for Firefox 3.6
    - remove debian/firefox.xml.in
    - update debian/firefox-gnome-support.install.in
    - update debian/rules
  * Ship Test Pilot as a distribution addon, like upstream. This means
    that the addon manager can update it. It does also mean that it will
    remain installed in users profiles if they try the beta or aurora
    builds, but the Feedback button is disabled on release builds
    - update debian/firefox.install.in
    - fixes LP: #913357
  * Drop patches fixed upstream
    - remove debian/patches/fix-cursor-handling.patch
    - update debian/patches/series
  * Call xvfb-run with "-a" in case there are other servers running on the
    builder
    - update debian/build/testsuite.mk
  * Really fix LP: #898883 - IPC xpcshell tests hang the build. What was
    actually happening is plugin-container would fail to start because all
    available X connections had been used up by many instances of dbus-launch,
    spawned each time an xpcshell tried to talk to the session bus. Because
    we run all of the xpcshell tests with one Xvfb instance, the buses
    accumulate until the available X connections all run out. To fix this, run
    all tests requiring a display inside dbus-launch, so we create just a
    single bus for all xpcshell tests
    - update debian/build/testsuite.mk
    - update debian/control{,.in}
  * Add Ligurian to locale blacklist, as we don't support this in Ubuntu
    - update debian/config/locales.blacklist
  * Fix LP: #918763 - Revert the temporary investigation patch for
    bmo: #621446, as it breaks GCC4.4
    - add debian/patches/revert-bmo621446-investigation.patch
    - update debian/patches/series
  * Refresh patches
    - update debian/patches/ubuntu-ua-string-chan...

Read more...

Changed in firefox (Ubuntu Lucid):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (4.4 KiB)

This bug was fixed in the package firefox - 11.0+build1-0ubuntu0.10.10.2

---------------
firefox (11.0+build1-0ubuntu0.10.10.2) maverick-security; urgency=low

  * New upstream stable release (FIREFOX_11_0_BUILD1)
    - see LP: #951250 for USN information

  * Rebuilt against updated gcc to fix LP: #931637
  * Ensure that the crash reporter is disabled if rebuilt by Ubuntu
    derivatives, as there will be no crash symbols for those
    - update debian/rules
  * Only add "Ubuntu" to the UA string when being built for Ubuntu
    - update debian/rules
  * Temporarily disable ipdl tests due to build failures. These aren't
    enabled upstream, anyway
    - update debian/config/mozconfig.in
  * Always set the update channel - not setting it at build-time on release
    builds breaks the extensions.checkCompatibility pref. The only things
    using it at runtime are nsBlocklistService, Test Pilot (beta + aurora)
    and the about dialog (where the channel is hidden anyway)
    - update debian/rules
    - update debian/firefox.install.in
  * Fix LP: #898883 - IPC xpcshell tests hang the buildd's. Give all
    xpcshell tests an X display, as plugin-container won't work without one
    - update debian/build/testsuite.mk
  * Turn on all IPC xpcshell tests again
    - update debian/build/testsute.mk
  * Drop the default-apps xml file - there is already one provided by
    gnome-control-center, so ours duplicates this. We never used to install
    it for Firefox 3.6
    - remove debian/firefox.xml.in
    - update debian/firefox-gnome-support.install.in
    - update debian/rules
  * Ship Test Pilot as a distribution addon, like upstream. This means
    that the addon manager can update it. It does also mean that it will
    remain installed in users profiles if they try the beta or aurora
    builds, but the Feedback button is disabled on release builds
    - update debian/firefox.install.in
    - fixes LP: #913357
  * Drop patches fixed upstream
    - remove debian/patches/fix-cursor-handling.patch
    - update debian/patches/series
  * Call xvfb-run with "-a" in case there are other servers running on the
    builder
    - update debian/build/testsuite.mk
  * Really fix LP: #898883 - IPC xpcshell tests hang the build. What was
    actually happening is plugin-container would fail to start because all
    available X connections had been used up by many instances of dbus-launch,
    spawned each time an xpcshell tried to talk to the session bus. Because
    we run all of the xpcshell tests with one Xvfb instance, the buses
    accumulate until the available X connections all run out. To fix this, run
    all tests requiring a display inside dbus-launch, so we create just a
    single bus for all xpcshell tests
    - update debian/build/testsuite.mk
    - update debian/control{,.in}
  * Add Ligurian to locale blacklist, as we don't support this in Ubuntu
    - update debian/config/locales.blacklist
  * Fix LP: #918763 - Revert the temporary investigation patch for
    bmo: #621446, as it breaks GCC4.4
    - add debian/patches/revert-bmo621446-investigation.patch
    - update debian/patches/series
  * Refresh patches
    - update debian/patches/ubuntu-ua...

Read more...

Changed in firefox (Ubuntu Maverick):
status: New → Fix Released

Build 11.0+build1-0ubuntu0.10.04.2 fixes the bug for me - thanks a lot for the quick fix!

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

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.

mmalmeida (mmalmeida) wrote :

Unfortunately the bug wasn't fixed with the most recent update.

I've just tested it and got a firefox crash twice. You can see the crash reports in:

https://crash-stats.mozilla.com/report/index/8aecb253-e6ea-475c-9d06-d03152120316
https://crash-stats.mozilla.com/report/index/2064d731-18ad-446a-adb8-ca1202120316

mmalmeida (mmalmeida) wrote :

Also, the steps described in comment #6 produced the crash with the report https://crash-stats.mozilla.com/report/pending/144d8eee-0384-4766-bdd7-d88942120316

Chris Coulson (chrisccoulson) wrote :

I just tested it and it works fine here. Perhaps you're experiencing a different issue? I even disassembled the new binary and the issue I found, as detailed on the upstream bug report ,appears to be fixed now.

Changed in firefox:
importance: Unknown → Critical
status: Unknown → Confirmed
mmalmeida (mmalmeida) wrote :

@Chris: like I said, I've tried out the test case described in https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/931637/comments/6 and the result is the crash. So the consequence of the crash is the same. I don't know if the origin is...

mmalmeida (mmalmeida) wrote :

In addition, on the same machine, if I run a clean firefox downloaded from mozilla's site (ie, unpackage it to a directory and running it from the command line with " ./firefox -p testeBugs -no-remote") I get no crash following comment #6's test case.

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

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gcc-4.4 (Ubuntu Oneiric):
status: New → Confirmed

I've to support @wild_oscar, latest updates didn't solve the problem for me.
Now I'm using firefox 11.0+build1-0ubuntu0.10.10.2 on Ubuntu 10.10 x86_64 and firefox still crashes each time I try test case described at https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/931637/comments/6 , see my latest crash report at https://crash-stats.mozilla.com/report/index/04a7ded2-29e7-4e6f-b200-23de52120320.
Also firefox crashes almost instantly after switching to the DOM tab in Firebug, so recent updates didn't improve anything related to this bug.

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>

Ben Turner (ben-turner) wrote :

Also getting this problem for a long time now (and still ongoing) with Ubuntu 10.10 (Maverick) and FF9,10 & 11

I'm running firefox 11.0+build1-0ubuntu0.10.10.2 on on Ubuntu 10.10 x86_64 and can crash firefox by typing:
* CTRL+SHIFT+K
* print

It crashes everytime when I get to "i", as also noted by @pdescham49

mmalmeida (mmalmeida) wrote :

I have the following packages in Maverick 10.10:

firefox 11.0+build1-0ubuntu0.10.10.2
gcc 4:4.4.4-1ubuntu2

I still see this issue, so the fix doesn't seem to be working.

Any update on the subject?

Created attachment 632053
Workaround which only affects DEBUG builds

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

Comment on attachment 632053
Workaround which only affects DEBUG builds

Review of attachment 632053:
-----------------------------------------------------------------

::: 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. */

Created attachment 632144
Workaround which only affects DEBUG builds v2

Redid comment. The problem actually affects both ARM and x86

Changed in firefox:
status: Confirmed → Fix Released
Download full text (5.6 KiB)

I still get intermittent crashes In FF 9-11 on ubuntu when I play with the
dom inspector. Granted it's in Firebug I'll see if I can get it to crash
with some of the native FF debugging tools.

Paul

On Sun, Apr 22, 2012 at 10:22 PM, Ben Turner <email address hidden>wrote:

> Also getting this problem for a long time now (and still ongoing) with
> Ubuntu 10.10 (Maverick) and FF9,10 & 11
>
> I'm running firefox 11.0+build1-0ubuntu0.10.10.2 on on Ubuntu 10.10 x86_64
> and can crash firefox by typing:
> * CTRL+SHIFT+K
> * print
>
> It crashes everytime when I get to "i", as also noted by @pdescham49
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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:
> Confirmed
>
> 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
> Subde...

Read more...

pdescham49 (pdescham49) wrote :
Download full text (5.8 KiB)

Comfirmed.

CTRL-SHIFT-K

typed in print

CRASH

On Thu, Jun 14, 2012 at 9:20 AM, Paul Deschamps <email address hidden>wrote:

> I still get intermittent crashes In FF 9-11 on ubuntu when I play with the
> dom inspector. Granted it's in Firebug I'll see if I can get it to crash
> with some of the native FF debugging tools.
>
> Paul
>
>
> On Sun, Apr 22, 2012 at 10:22 PM, Ben Turner <email address hidden>wrote:
>
>> Also getting this problem for a long time now (and still ongoing) with
>> Ubuntu 10.10 (Maverick) and FF9,10 & 11
>>
>> I'm running firefox 11.0+build1-0ubuntu0.10.10.2 on on Ubuntu 10.10
>> x86_64 and can crash firefox by typing:
>> * CTRL+SHIFT+K
>> * print
>>
>> It crashes everytime when I get to "i", as also noted by @pdescham49
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> 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:
>> Confirmed
>>
>> 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
>> ...

Read more...

Adolfo Jayme (fitojb) on 2013-06-27
no longer affects: firefox (Ubuntu Natty)
no longer affects: firefox (Ubuntu Oneiric)
no longer affects: gcc-4.4 (Ubuntu Natty)
no longer affects: gcc-4.4 (Ubuntu Oneiric)

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Paul

Paul Deschamps
Corporate Systems Developer at QNX Software Systems
Ottawa, Canada Area

Confirm that you know Paul Deschamps:
https://www.linkedin.com/e/-q6i8oz-hrhziv2z-2x/isd/20007315972/CnibuRoR/?hs=false&tok=2kYK4n6K9q1681

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-q6i8oz-hrhziv2z-2x/z8bfwdl555HaKsVz-45sXNx5LSA7Emp8vcouniC/goo/931637%40bugs%2Elaunchpad%2Enet/20061/I6448785860_1/?hs=false&tok=0VVCDYHK5q1681

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

Paul White (paulw2u) on 2018-08-19
Changed in firefox (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.