[armel] thunderbird-bin crashed with SIGSEGVI

Bug #385325 reported by Michael Casadevall
34
This bug affects 2 people
Affects Status Importance Assigned to Milestone
lightning-sunbird (Ubuntu)
Undecided
Unassigned
Jaunty
Undecided
Unassigned
Karmic
Undecided
Unassigned
thunderbird (Ubuntu)
High
Michael Casadevall
Jaunty
Medium
Michael Casadevall
Karmic
High
Michael Casadevall

Bug Description

Binary package hint: thunderbird

Starting thunderbird by itself on karmic will segfault, and is a continuing issue from jaunty.

Thunderbird Version:
 Thunderbird 2.0.0.21, Copyright (c) 1998-2009 mozilla.org

ProblemType: Crash
Architecture: armel
Date: Tue Jun 9 15:03:28 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/lib/thunderbird/thunderbird-bin
Package: thunderbird 2.0.0.21+nobinonly-0ubuntu1.9.04.1
ProcCmdline: /usr/lib/thunderbird/thunderbird-bin
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-11.42-imx51
Signal: 11
SourcePackage: thunderbird
Stacktrace: #0 0x4004899c in ?? () from /usr/lib/thunderbird/libmozjs.so
StacktraceTop: ?? () from /usr/lib/thunderbird/libmozjs.so
Title: thunderbird-bin crashed with SIGSEGV
Uname: Linux 2.6.28-11-imx51 armv7l
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Revision history for this message
Michael Casadevall (mcasadevall) wrote :
Changed in thunderbird (Ubuntu):
assignee: nobody → Michael Casadevall (mcasadevall)
importance: Undecided → High
milestone: none → karmic-alpha-3
Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt (retraced)

StacktraceTop:mult (a=0x2ac5d8, b=0x2ac5f8) at jsdtoa.c:659
pow5mult (b=0x2ac5f8, k=1185) at jsdtoa.c:789
JS_dtostr (buffer=0xbe9c98e6 "�\b�\005",
js_NumberToString (cx=0x5b4f0, d=2147500034) at jsnum.c:724
js_ValueToString (cx=0x5b4f0, v=2742650) at jsstr.c:2689

Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt (retraced)
Changed in thunderbird (Ubuntu):
importance: High → Medium
tags: removed: need-armel-retrace
description: updated
summary: - [armel] thunderbird-bin crashed with SIGSEGV
+ [armel] thunderbird-bin crashed with SIGSEGVI
visibility: private → public
Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Talked with asac, this issue doesn't current with the current beta snapshots of Thunderbird 3, so its an issue with the older codebase.

Changed in thunderbird (Ubuntu):
status: New → Confirmed
Revision history for this message
Michael Casadevall (mcasadevall) wrote :
Download full text (17.9 KiB)

Redone backtrace with optimization disabled, and --enable-debug built into thunderbird, with a patch applied to get --enable-debug to build:

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/mcasadevall/src/thunderbird-2.0.0.21+nobinonly/build-tree/mozilla/dist/bin/thunderbird-bin
[Thread debugging using libthread_db enabled]
[New Thread 0x411e85e0 (LWP 31113)]
No Persistent Registry Found.
Type Manifest File: /home/mcasadevall/src/thunderbird-2.0.0.21+nobinonly/build-tree/mozilla/dist/bin/components/xpti.dat
*** Registering Apprunner components (all right -- a generic module!)
nsNativeComponentLoader: autoregistering begins.
*** Registering mozgnome components (all right -- a generic module!)
*** Registering necko_secondary_protocols components (all right -- a generic module!)
*** Registering embedcomponents components (all right -- a generic module!)
*** Registering nsFileViewModule components (all right -- a generic module!)
*** Registering nsImportServiceModule components (all right -- a generic module!)
*** Registering nsWidgetGtk2Module components (all right -- a generic module!)
*** Registering BOOT components (all right -- a generic module!)
*** Registering JavaScript_Debugger components (all right -- a generic module!)
*** Registering nsMailCompsModule components (all right -- a generic module!)
*** Registering nsTransactionManagerModule components (all right -- a generic module!)
*** Registering nsUCvMathModule components (all right -- a generic module!)
*** Registering nsMorkModule components (all right -- a generic module!)
*** Registering nsComposerModule components (all right -- a generic module!)
*** Registering nsEditorModule components (all right -- a generic module!)
*** Registering mozMySpellModule components (all right -- a generic module!)
*** Registering nsJarModule components (all right -- a generic module!)
*** Registering nsPrefModule components (all right -- a generic module!)
*** Registering nsUniversalCharDetModule components (all right -- a generic module!)
*** Registering nsGfxPSModule components (all right -- a generic module!)
*** Registering nsWebServicesModule components (all right -- a generic module!)
*** Registering nsAuthModule components (all right -- a generic module!)
*** Registering nsRDFModule components (all right -- a generic module!)
*** Registering xpcomObsoleteModule components (all right -- a generic module!)
*** Registering nsAccessibilityModule components (all right -- a generic module!)
*** Registering Browser_Embedding_Module components (all right -- a generic module!)
*** Registering nsWalletModule components (all right -- a generic module!)
*** Registering nsImageLib2Module components (all right -- a generic module!)
*** Registering nsLayoutModule components (all right -- a generic module!)
*** Registering application components (all right -- a generic module!)
*** Registering nsGfxGTKModule components (all right -- a generic module!)
*** Registering nsToolkitCompsModule components (all right -- a generic module!)
*** Registering nsFindComponent components (all right -- a generic module!)
*** Registering PKI com...

Revision history for this message
Michael Casadevall (mcasadevall) wrote :

I've been talking with Alexander Sac. As it stands, Thunderbird 3 properly works, and there has been no code changes that could explain the working behavior in mult() or Balloc(); there have been considerable changes elsewhere in Thunderbird 3, which would make isolating the specific change to correct the segfault extremely difficult, and time consuming, and even if the specific commit is isolated, it may not be backport-able.

According to asac, TB 2 is mostly inactive, and its unlikely there would be consider help in resolving this issue; and searching the Mozilla bugzilla has not turned up any bugs opened or provided any clues on what was changed to fix the crash in TB3.

Revision history for this message
Loïc Minier (lool) wrote :

The backtrace in https://bugzilla.mozilla.org/show_bug.cgi?id=385583 looks similar; this bug relates to ARM EABI support and the patch seems to apply to thunderbird/mozilla/nsprpub; it looks like it could fix this bug:
https://bug385583.bugzilla.mozilla.org/attachment.cgi?id=347009

Revision history for this message
Loïc Minier (lool) wrote :

I think we want to patch the nspr source package where this patch seems to apply; thunderbird bdeps on libnspr4-dev.

Revision history for this message
Dave Martin (dave-martin-arm) wrote :

If tb2 can't easily be fixed, will tb3 be made available in jaunty as a backport or update?

I'd be concerned if there will not be any working version of tb at all in jaunty.

Revision history for this message
Loïc Minier (lool) wrote :

Alexander uploaded a fixed nspr to karmic; could someone please confirm it fixes the bug?

I've added this patch alone to jaunty's nspr; I'd love if someone could confirm the attached .deb fixes the issue for jaunty.

Revision history for this message
Dave Martin (dave-martin-arm) wrote :

Doesn't seem to work for me, I'm afraid. Thunderbird (2.0.0.21+nobinonly-0ubuntu1.9.04.1) still segfaults with the same symptoms.

Revision history for this message
Loïc Minier (lool) wrote :

Ah, asac recommended respinning Thunderbird which definitely makes sense: these are macros used all over the place, the code is not necessarily in the nspr shared lib. asac will push a respin of tb to karmic.

Revision history for this message
Dave Martin (dave-martin-arm) wrote :
Download full text (4.6 KiB)

MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.:./plugins:.
DISPLAY=:0.0
DYLD_LIBRARY_PATH=.:.
     LIBRARY_PATH=.:./components:.
       SHLIB_PATH=.:.
          LIBPATH=.:.
       ADDON_PATH=.
      MOZ_PROGRAM=/usr/lib/thunderbird/thunderbird-bin
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=gdb
/usr/bin/gdb /usr/lib/thunderbird/thunderbird-bin -x /tmp/mozargs.ZsTAko
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi"...
(gdb) r
Starting program: /usr/lib/thunderbird/thunderbird-bin
[Thread debugging using libthread_db enabled]
[New Thread 0x40f6b4c0 (LWP 7214)]
[New Thread 0x42e30440 (LWP 7217)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x40f6b4c0 (LWP 7214)]
0x4004899c in mult (a=0x2d9400, b=0x2d9420) at jsdtoa.c:659
659 jsdtoa.c: No such file or directory.
 in jsdtoa.c
Current language: auto; currently c
(gdb) backtrace
#0 0x4004899c in mult (a=0x2d9400, b=0x2d9420) at jsdtoa.c:659
#1 0x40049598 in pow5mult (b=0x2d9420, k=1185) at jsdtoa.c:789
#2 0x4004b738 in JS_dtostr (buffer=0xbe9a5846 "Ã@\020\204\a",
    bufferSize=621765855, mode=DTOSTR_STANDARD, precision=0,
    d=8.2265532824141687e-308) at jsdtoa.c:2493
#3 0x40073aac in js_NumberToString (cx=0x783f8, d=2147500034) at jsnum.c:724
#4 0x400a3b2c in js_ValueToString (cx=0x783f8, v=3101778) at jsstr.c:2689
#5 0x400595a4 in js_ReportUncaughtException (cx=0x783f8) at jsexn.c:1290
#6 0x40032428 in JS_CallFunctionValue (cx=0x783f8,
    obj=<value optimized out>, fval=<value optimized out>,
    argc=<value optimized out>, argv=0xbe9a5964, rval=0x783f8) at jsapi.c:4390
#7 0x4174ed40 in nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject (
    this=<value optimized out>, ccx=<value optimized out>, jsobj=0x2f53e8,
    aIID=@0x41765bb8) at xpcwrappedjsclass.cpp:278
#8 0x4174ee24 in nsXPCWrappedJSClass::GetRootJSObject (this=0x2d9460,
    ccx=@0x2d9400, aJSObj=0x0) at xpcwrappedjsclass.cpp:674
#9 0x4174c38c in nsXPCWrappedJS::GetNewOrUsed (ccx=@0xbe9a5a1c,
    aJSObj=0x2f53e8, aIID=@0x41768d60, aOuter=0x0, wrapperResult=0xbe9a59d4)
    at xpcwrappedjs.cpp:242
#10 0x4173e388 in XPCConvert::JSObject2NativeInterface (ccx=@0xbe9a5a1c,
    dest=0xbe9a5af4, src=0x2f53e8, iid=0x41768d60, aOuter=0x0,
    pErr=0xbe9a5a94) at xpcconvert.cpp:1253
#11 0x4173120c in nsXPConnect::WrapJS (this=<value optimized out>,
    aJSContext=<value optimized out>, aJSObj=0x2f53e8, aIID=@0x41768d60,
    result=0xbe9a5af4) at nsXPConnect.cpp:647
#12 0x41763280 in mozJSComponentLoader::ModuleForLocation (this=0x8ac38,
    registryLocation=0x2bf868 "rel:nsMailDefaultHandler.js",
    component=<value optimized out>, status=0xbe9a5c5c)
    at mozJSComponentLoader.cpp:1007
#13 0x4176377c in mozJSComponentLoader::AttemptRegistration (this=0x8ac38,
    component=0x274260, deferred=2573064) at mozJSComponentLoader.cpp:761
#14 0x41763c50 in mozJSComponentLoader...

Read more...

Revision history for this message
Loïc Minier (lool) wrote :

So the backtrace looked similar as in the upstream bug I mentionned, but attempts at using the upstream patch didn't help. One last thing to try is patching libnss and running TB against that. Michael is also trying a full clean upstream build of TB with the patch.

If that doesn't work, we could contact the upstream submitter in case he has a different fix or we could bisect or debug the issue directly.

Loïc Minier (lool)
Changed in thunderbird (Ubuntu Karmic):
milestone: karmic-alpha-3 → ubuntu-9.10-beta
Revision history for this message
Michael Casadevall (mcasadevall) wrote :
Download full text (7.0 KiB)

After another round of debugging this weekend, and googling, I managed to make some progress on this. Here's a quick technical examination; The initial issue is caused by a change on old ARM ABI, and new ARM ABI with respect to the handling of floating point operations. Without going into too much detail, the main issue came from the behavior of OABI ARM when using the FPA API; although ARM is traditionally a little endian architecture (with a handful of big-endian systems existing), in OABI ARM, the FPU (or FPU emulation) always took big-endian formatted doubles vs. little-endian doubles; any application which did bitwise operations on doubles needed to be aware of this and treat any doubles as big-endian while handling any non-FPU operation as little-endian. On EABI systems which mandate the VFP FPU format, all doubles are little-endian; newer versions of thunderbird and firefox have been properly patched to handle this, but thunderbird lacked the necessary change.

I was tipped off to this quirk in OABI ARM by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215067, which shows that NSPR segfaults if you try to pass very large numbers into it. A look at the backtrace reveals this happens in in the Javascript library; specifically:

#3 0x40073aac in js_NumberToString (cx=0x783f8, d=2147500034) at jsnum.c:724

and the end result can be seen in:

#2 0x4004b738 in JS_dtostr (buffer=0xbe9a5846 "Ã@\020\204\a",
    bufferSize=621765855, mode=DTOSTR_STANDARD, precision=0,
    d=8.2265532824141687e-308) at jsdtoa.c:2493

(this function coverts a double to a string, with d going in being close to the max. size of doubles on the ARM architecture).

The value is then passed into NSPR, which tries to use memory more memory than its allocated, and promptly segfaults (a more indepth explination of this behavior is in the original Debian bug). Loic's patch corrects a different behavior in NSPR that prevents mult()/Balloc() from working when using NSPR's user-land thread emulation, and not the system pthreads library; configure output suggests we do indeed use pthreads vs. NSPR's emulation. A couple of grep's later, and I found the necessary preprocessor macro's to change to force LITTLE_ENDIAN behavior in libjzmoz. The upshot is that the import wizard now runs (although it comes up with the window very large), and then thunderbird segfaults again, this time in fontconfig (the backtrace is incomplete, I'll post a more complete one later).

As it stands, I need to clean up my patch and source tree, so I'll post my current debdiff once I do that so others can continue to build off the work I've started. I'm hoping the current segfault is simply a side-effect from a non-clean build-environment.

My current backtrace:
(gdb) bt
#0 FcPatternObjectAddWithBinding (p=0x0, object=1, value=
        {type = 3439344, u = {s = 0x1 <Address 0x1 out of bounds>, i = 1, b = 1, d = 2.121995791459338e-314, m = 0x1, c = 0x1, f = 0x1, l = 0x1}}, binding=390632, append=1) at fcpat.c:476
#1 0x40a37230 in FcPatternObjectAdd (p=0x0, object=1, value=
        {type = 3439344, u = {s = 0x1 <Address 0x1 out of bounds>, i = 1, b = 1, d = 495.00000000000006, m = 0x1, c = 0x1, f = 0x1,...

Read more...

Changed in thunderbird (Ubuntu Jaunty):
assignee: nobody → Michael Casadevall (mcasadevall)
importance: Undecided → Medium
milestone: none → jaunty-updates
status: New → Confirmed
Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Here's my current debdiff and gdb backtrace (as complete as I can get it; something in Thunderbird is preventing from seeing the entire stack). It seems we might have tripped a pango/fontconfig bug, as it seems too deep in the pango stack to be a bug from thunderbird. Googling around reveals this gem of a bug report: https://bugs.maemo.org/show_bug.cgi?id=3150

Since I'm currently building thunderbird -O0 to help improve backtraces, its possible I'm tripped the bug reported in maemo. I'm currently rebuilding TB2 with its normal optimization settings to see if it changes anything.

Revision history for this message
Michael Casadevall (mcasadevall) wrote :
Revision history for this message
Loïc Minier (lool) wrote :

I've backported upstream commit 2538:3f78d5e894bc from http://hg.mozilla.org/releases/mozilla-1.9.1/ which carries a similar change and also clarifies the macro names and comments.

Revision history for this message
Michael Casadevall (mcasadevall) wrote :
Download full text (33.6 KiB)

Here's a more complete backtrace with debugging enable and -O0 on pango and fontconfig. I tested TB with --disable-pango, no change in the trace, so it seems this issue is not TB specific.

mcasadevall@dawn:~/src/thunderbird-2.0.0.22+build1+nobinonly/build-tree/mozilla$ dist/bin/thunderbird -g
dist/bin/run-mozilla.sh -g dist/bin/thunderbird-bin
MOZILLA_FIVE_HOME=dist/bin
  LD_LIBRARY_PATH=dist/bin:dist/bin/plugins:/usr/lib/mre/mre-2.0.0.22
DISPLAY=localhost:10.0
DYLD_LIBRARY_PATH=dist/bin:/usr/lib/mre/mre-2.0.0.22
     LIBRARY_PATH=dist/bin:dist/bin/components:/usr/lib/mre/mre-2.0.0.22
       SHLIB_PATH=dist/bin:/usr/lib/mre/mre-2.0.0.22
          LIBPATH=dist/bin:/usr/lib/mre/mre-2.0.0.22
       ADDON_PATH=dist/bin
      MOZ_PROGRAM=dist/bin/thunderbird-bin
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
/usr/bin/gdb dist/bin/thunderbird-bin -x /tmp/mozargs.CSf6z5
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi"...
(gdb) set pagination 0
(gdb) handle SIG33 pass nostop noprint
Signal Stop Print Pass to program Description
SIG33 No No Yes Real-time event 33
(gdb) r
Starting program: /home/mcasadevall/src/thunderbird-2.0.0.22+build1+nobinonly/build-tree/mozilla/dist/bin/thunderbird-bin
[Thread debugging using libthread_db enabled]
[New Thread 0x412365f0 (LWP 11375)]
Type Manifest File: /home/mcasadevall/.mozilla-thunderbird/am3ei364.default/xpti.dat
*** Registering Apprunner components (all right -- a generic module!)
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nsNativeComponentLoader: registering deferred (0)
pldhash: for the table at address 0xb45c0, the given entrySize of 44 probably favors chaining over double hashing.
[New Thread 0x42291430 (LWP 11378)]
[New Thread 0x435bf430 (LWP 11380)]
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=24
++WEBSHELL == 1
[New Thread 0x4479c430 (LWP 11381)]
++DOMWINDOW == 1

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x412365f0 (LWP 11375)]
FcPatternObjectAddWithBinding (p=0x0, object=1, value={type = 3448088, u = {s = 0x1 <Address 0x1 out of bounds>, i = 1, b = 1, d = 2.121995791459338e-314, m = 0x1, c = 0x1, f = 0x1, l = 0x1}}, binding=FcValueBindingStrong, append=1) at fcpat.c:476
476 if (p->ref == FC_REF_CONSTANT)
Current language: auto; currently c
(gdb) backtrace full
#0 FcPatternObjectAddWithBinding (p=0x0, object=1, value={type = 3448088, u = {s = 0x1 <Address 0x1 out of bounds>, i = 1, b = 1, d = 2.121995791459338e-314, m = 0x1, c = 0x1, f = 0x1, l = 0x1}}, binding=FcValueBindingStrong, append=1) at fcpat.c:476
 e = <value optimized out>
 new = <value optimized out>
 prev = <value optimized out>
#1 0x40a64c10 in FcPatternObjectAdd (p=0x0, object=1, value={type = 3448088, u = {s = 0x1 <Address 0x1 out of bounds>, i = 1, b = 1, d = 4.9406564584124654e-324, m = 0x1, c = 0x1, f ...

Revision history for this message
Michael Casadevall (mcasadevall) wrote :
Download full text (12.7 KiB)

Debugging continues. I think we found either a memory corruption or race condition within fontconfig. When the following patch (http://paste.ubuntu.com/203007/) was applied to fontconfig in an attempt to try and find why FcPatternBuild was returning 0x0, the backtrace changed dramatically. Here's the new backtrace, but there is no telling if this segfault is valid if we have a possible memory corruption issue on fontconfig.

(gdb) r
Starting program: /home/mcasadevall/src/thunderbird-2.0.0.22+build1+nobinonly/build-tree/mozilla/dist/bin/thunderbird-bin
[Thread debugging using libthread_db enabled]
[New Thread 0x412365f0 (LWP 24364)]
Type Manifest File: /home/mcasadevall/.mozilla-thunderbird/am3ei364.default/xpti.dat
*** Registering Apprunner components (all right -- a generic module!)
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nsNativeComponentLoader: registering deferred (0)
pldhash: for the table at address 0xb45e0, the given entrySize of 44 probably favors chaining over double hashing.
[New Thread 0x42291430 (LWP 24365)]
[New Thread 0x435bf430 (LWP 24367)]
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=24
++WEBSHELL == 1
[New Thread 0x4479c430 (LWP 24368)]
++DOMWINDOW == 1
Returning 3477808
++DOMWINDOW == 2
###!!! ASSERTION: id differs from id in atom table!: 'd_val == idval', file xpcwrappednativejsops.cpp, line 1046
Break: at file xpcwrappednativejsops.cpp, line 1046
###!!! ASSERTION: Can't get globalObject.Object.prototype: 'Error', file xpcwrappednativescope.cpp, line 200
Break: at file xpcwrappednativescope.cpp, line 200
###!!! ASSERTION: Can't get globalObject.Function.prototype: 'Error', file xpcwrappednativescope.cpp, line 212
Break: at file xpcwrappednativescope.cpp, line 212
###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property!

This is pretty much always bad. It usually means that native code is
making a callback to an interface implemented in JavaScript, but the
document where the JS object was created has already been cleared and the
global properties of that document's window are *gone*. Generally this
indicates a problem that should be addressed in the design and use of the
callback code.
: 'Error', file xpcwrappednativescope.cpp, line 574
Break: at file xpcwrappednativescope.cpp, line 574

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x412365f0 (LWP 24364)]
0x40033e04 in JS_GetClass (cx=0x2e6eb0, obj=0x0) at jsapi.c:2288
2288 JSVAL_TO_PRIVATE(GC_AWARE_GET_SLOT(cx, obj, JSSLOT_CLASS));
(gdb) bt full
#0 0x40033e04 in JS_GetClass (cx=0x2e6eb0, obj=0x0) at jsapi.c:2288
No locals.
#1 0x43c0a23c in nsDOMClassInfo::PostCreate (this=0x31ecc0, wrapper=0x45c550, cx=0x2e6eb0, obj=0x455508) at nsDOMClassInfo.cpp:3229
 proto_proto = (JSObject *) 0x0
 val = 4572496
 sSupportsIID = (const nsIID *) 0x43d27f14
 proto = (JSObject *) Cannot access memory at address 0xfffffff8
(gdb) bt
#0 0x40033e04 in JS_GetClass (cx=0x2e6eb0, obj=0x0) at jsapi.c:2288
#1 0x43c0a23c in nsDOMClassInfo::PostCreate (this=0x31ecc0, wrapper=0x45c550, cx=0x2e6eb0, obj=0x455508) at nsDOMClassInfo.cpp:3229
#2 0x418c7250 in XPCWrappedNative::Get...

Revision history for this message
Michael Casadevall (mcasadevall) wrote :
Download full text (7.2 KiB)

Based on advice from #ubuntu-mozillateam, I found and ran the test suite; here's the output

Running TestVersionComparator tests
All comparisons OK
../../dist/bin/run-mozilla.sh ../../dist/bin/test_all.sh ../../dist/bin/test_xpcom
../../dist/bin/test_xpcom/test_storagestream.js: PASS

../../dist/bin/run-mozilla.sh ../../dist/bin/necko_unit_tests/test_all.sh
../../dist/bin/necko_unit_tests/test_bug331825.js: FAIL (see ../../dist/bin/necko_unit_tests/test_bug331825.js.log)
../../dist/bin/necko_unit_tests/test_bug336501.js: PASS
../../dist/bin/necko_unit_tests/test_content_sniffer.js: FAIL (see ../../dist/bin/necko_unit_tests/test_content_sniffer.js.log)
../../dist/bin/necko_unit_tests/test_cookie_header.js: FAIL (see ../../dist/bin/necko_unit_tests/test_cookie_header.js.log)
../../dist/bin/necko_unit_tests/test_event_sink.js: FAIL (see ../../dist/bin/necko_unit_tests/test_event_sink.js.log)
../../dist/bin/necko_unit_tests/test_http_headers.js: FAIL (see ../../dist/bin/necko_unit_tests/test_http_headers.js.log)
../../dist/bin/necko_unit_tests/test_parse_content_type.js: PASS
../../dist/bin/necko_unit_tests/test_protocolproxyservice.js: FAIL (see ../../dist/bin/necko_unit_tests/test_protocolproxyservice.js.log)

Oh no! ../../dist/bin/necko_unit_tests/test_all.sh just dumped a core file.

Here're the log files:
mcasadevall@dawn:~/src/thunderbird-2.0.0.22+build1+nobinonly/build-tree/mozilla/dist/bin/necko_unit_tests$ cat *.log
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nsNativeComponentLoader: registering deferred (0)
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsStringBundle.cpp, line 273
pldhash: for the table at address 0xf7588, the given entrySize of 44 probably favors chaining over double hashing.
###!!! ASSERTION: no native to utf-16 converter: 'gNativeToUnicode != INVALID_ICONV_T', file nsNativeCharsetUtils.cpp, line 374
Break: at file nsNativeCharsetUtils.cpp, line 374
###!!! ASSERTION: no utf-16 to native converter: 'gUnicodeToNative != INVALID_ICONV_T', file nsNativeCharsetUtils.cpp, line 375
Break: at file nsNativeCharsetUtils.cpp, line 375
Segmentation fault (core dumped)
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nsNativeComponentLoader: registering deferred (0)
WARNING: nsExceptionService ignoring thread destruction after shutdown, file nsExceptionService.cpp, line 191
WARNING: No event queue listener?, file nsEventQueue.cpp, line 79
Type Manifest File: /home/mcasadevall/src/thunderbird-2.0.0.22+build1+nobinonly/build-tree/mozilla/dist/bin/components/xpti.dat
*** test pending
*** test finished
*** exiting
*** PASS ***
nsStringStats
 => mAllocCount: 1406
 => mReallocCount: 977
 => mFreeCount: 1406
 => mShareCount: 1706
 => mAdoptCount: 181
 => mAdoptFreeCount: 180 -- LEAKED 1 !!!
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nsNativeComponentLoader: registering deferred (0)
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsStringBundle.cpp, line 273
pldhash: for the table at address 0xfe2c8, ...

Read more...

Revision history for this message
Michael Casadevall (mcasadevall) wrote :

asac tipped me off that there are some tests that aren't automatically run, and with that, and his assistance on locating possible changesets to backport, I can claim I've successfully run TB2 on ARM and downloaded my inbox with it. Patch attached. I'm now creating a new branch with both this patch, and the other one. The stack corruption seen in fontconfig was actually an issue with the stack on ARM caused in xpinvoke.

Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Fix committed on karmic. Waiting on an all-arch test build before we upload to karmic.

Changed in thunderbird (Ubuntu Karmic):
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunderbird - 2.0.0.22+build1+nobinonly-0ubuntu1.nspr474

---------------
thunderbird (2.0.0.22+build1+nobinonly-0ubuntu1.nspr474) karmic; urgency=low

  * security/stability update 2.0.0.22 (USN-782-1)
  * add patch to fix ftbfs with gcc 4.4 (s/elif/else/)
    - add debian/patches/ftbfs_gcc44_elif.patch
    - update debian/patches/series
  * fix LP: #345189 - thunderbird 2 treats pixel sized system fonts as
    if they were point sized, which causes for to HUGE fonts
    - add debian/patches/lp345189_absolute_font_sizing.patch
    - update debian/patches/series
  * fix LP: #137221 - thunderbird-gnome-support package required for
    gnome capabilities; the gnome parts were always loadable modules and
    fail to load gracefully if depends cannot be fulfilled anyway; in turn
    we ship gnome components in the main thunderbird package and apply a bit
    magic in debian/rules to strip the gnome related dependencies from it;
    on top of this thunderbird-gnome-support becomes an empty package which gets
    all the dependencies for convenience; the purpose of new gnome-support is
    hence to install all required depends; in order to add the required depends
    to the gnome-support package we introduce a new substvar "shlibs:GnomeShlibs"
    and refer to it in control
    - remove debian/thunderbird-gnome-support.install
    - update debian/rules
    - update debian/control
  * the change for LP: #137221 moves files from thunderbird-gnome-support to
    thunderbird package; adding Replaces to thunderbird package accordingly
    - update debian/control
  * fix LP: #145716 - panel launcher breaks on upgrade; we provide a
    compatibility link for the old mozilla-thunderbird binary
    - update debian/thunderbird.links
  * drop not used control.in from debian/ dir
    - remove debian/control.in
  * pick up latest nspr (>= 4.7.4) to potentially fix armel build (LP: #385325)
    - update debian/control

 -- Alexander Sack <email address hidden> Tue, 16 Jun 2009 14:02:03 +0200

Changed in thunderbird (Ubuntu Karmic):
status: Fix Committed → Fix Released
Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Moving back to fixed commited, last upload accidently closed this bug.

Changed in thunderbird (Ubuntu Karmic):
status: Fix Released → Fix Committed
Loïc Minier (lool)
Changed in thunderbird (Ubuntu Karmic):
importance: Medium → High
Revision history for this message
Steve Langasek (vorlon) wrote :

Why does this remain fix committed for two weeks now? Wouldn't it be simpler to get it uploaded to the archive and test from there?

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunderbird - 2.0.0.22+build1+nobinonly-0ubuntu2

---------------
thunderbird (2.0.0.22+build1+nobinonly-0ubuntu2) karmic; urgency=low

  [ Loic Minier ]
  * fix LP: #385325 - crash in JS due to usage of wrong floating point number format;
    thanks Michael Casadevall for the research and locating the fix; patch created from
    hg rev 2538:3f78d5e894bc aka bmo #322806
    - add debian/patches/bz322806_arm-vfp-2538:3f78d5e894bc
    - update debian/patches/series

  [ Michael Casadevall ]
  * fix LP: #385325 - stack corruption issues on ARM EABI by cherry picking
    patch from 1.9 branch.
    - add debian/patches/bz339782_cvs_xptcinvoke_arm_backport_1.13.patch
    - update debian/patches/series
  * fix build failures on armel by changing default compiler on ARM to gcc-4.3
    and adding armel specific build depend accordingly
    - update debian/rules
    - update debian/control

 -- Alexander Sack <email address hidden> Fri, 10 Jul 2009 16:18:46 +0200

Changed in thunderbird (Ubuntu Karmic):
status: Fix Committed → Fix Released
Revision history for this message
John Vivirito (gnomefreak) wrote :

Added lightning task to make it easier for me to track. cherry picking a patch from thunderbird-2:
bz322806_arm-vfp-2538:3f78d5e894bc

Changed in lightning-sunbird (Ubuntu Karmic):
status: New → Triaged
Changed in lightning-sunbird (Ubuntu Jaunty):
status: New → Confirmed
Revision history for this message
Nazo (lovesyao) wrote :

I'm waiting to fix this bug on jaunty. any news?

Revision history for this message
Nazo (lovesyao) wrote :

oops, s/to fix/to be fixed/

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lightning-sunbird - 0.9+nobinonly-0ubuntu3

---------------
lightning-sunbird (0.9+nobinonly-0ubuntu3) karmic; urgency=low

  [ John Vivirito ]
  * Fixes (LP: #178785)
    - debian/rules: Added build option --enable-official-branding to build with official branding
    - debian/patches: Removed deb299697-lp42559-use-FC_ANY_METRICS.patch to fix build errors
    - debian/patches: Updated series
  * Fixes (LP: #399400)
    - debian/rules: Removed the convert icon section
    - debian/sunbird.links: Adjusted link to use the 128 icon
  * Fixes (LP: #401165)
    - debian/control: Removed GCC and GCC++ from build-deps
    - debian/rules: Commented out GCC and GCC++ lines to build using default
    - debian/patches: Added ftbfs_gcc44_elif.patch to fix FTBFS
    - debian/patches/series: Updated
  * Fixes (LP: #385325) crash in JS due to usage of wrong floating point number$
    - debian/patches: Added bz322806_arm-vfp-2538:3f78d5e894bc
    - debian/patches/series: Updated
  * Fixes (LP: #378754)
    - debian/control: Fixed typo in calendar-google-provider description.
  * Fixes (LP: #358084): add arm(el) xpcom patches from thunderbird package
    - add debian/patches/18_arm_xpcom_unused_attribute.dpatch
    - add debian/patches/38_arm_xpcom_optim.dpatch
    - add debian/patches/bz339782_cvs_xptcinvoke_arm_backport_1.13.patch
    - update debian/patches/series
  * debian/patches:
    - Add debian/patches/412610_attachment_309958.patch: to prevent crash on MAX_PATH
    - update debian/patches/series

 -- John Vivirito <email address hidden> Fri, 21 Aug 2009 10:57:02 -0400

Changed in lightning-sunbird (Ubuntu Karmic):
status: Triaged → Fix Released
Revision history for this message
Tobin Davis (gruemaster) wrote :

Marked Jaunty tasks as "Won't fix" as they are beyond our support cycle. This issue was resolved in later builds.

Changed in thunderbird (Ubuntu Jaunty):
status: Confirmed → Won't Fix
Changed in lightning-sunbird (Ubuntu Jaunty):
status: Confirmed → Won't Fix
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.