FS#49331 - [thunderbird] Does not start with Lightening extension

Attached to Project: Arch Linux
Opened by Janne Pettersson (wincc) - Saturday, 14 May 2016, 16:12 GMT
Last edited by Jan Alexander Steffens (heftig) - Sunday, 15 May 2016, 13:48 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Evangelos Foutras (foutrelis)
Jan Alexander Steffens (heftig)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 10
Private No

Details

Description:

When upgrading Thunderbird 45.0-1 -> 45.1.0-1 application does not start if not Lightning extension is disabled.

Have to start from commandline with: thunderbird -safe-mode

Additional info:
* package version(s)
* config and/or log files etc.

thunderbird-45.1.0.tar.bz2 from https://www.mozilla.org/en-US/thunderbird/ work as expected with Lightning enabled.

Steps to reproduce:
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Sunday, 15 May 2016, 13:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  45.1.0-2
Comment by Andrej Podzimek (andrej) - Sunday, 15 May 2016, 02:16 GMT
The same problem here.
Thanks for the workaround hint; disabling Lightning gets Thunderbird running.
45.0 worked fine for me and had Lightning enabled.
Comment by Carlo Abelli (cabellicar123) - Sunday, 15 May 2016, 04:00 GMT
Same problem here with version 45.1.0:

[calBackendLoader] Using libical backend at /home/username/.thunderbird/XXXXXXXX.default/extensions/{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}/components/libical-manifest
[1] 18690 segmentation fault (core dumped) thunderbird
Comment by Sachin Garg (randompie) - Sunday, 15 May 2016, 07:05 GMT
Same here. Reverting to 45.0
Comment by Stefano (senden9) - Sunday, 15 May 2016, 07:15 GMT
If it help somebody, here are some crash infos:

$ thunderbird --no-remote
[calBackendLoader] Using libical backend at /home/USERNAME/.thunderbird/xxx.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
[1] 7282 segmentation fault (core dumped) thunderbird --no-remote

$ coredumpctl gdb 7282
PID: 7282 (thunderbird)
UID: 1000 (USERNAME)
GID: 1000 (USERNAME)
Signal: 11 (SEGV)
Timestamp: Sun 2016-05-15 09:10:17 CEST (26s ago)
Command Line: thunderbird --no-remote
Executable: /usr/lib/thunderbird/thunderbird
Control Group: /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
Unit: user@1000.service
User Unit: user@1000.service
Slice: user-1000.slice
Owner UID: 1000 (USERNAME)
Boot ID: xxxx
Machine ID: xxxx
Hostname: USERNAME-PC
Coredump: /var/lib/systemd/coredump/core.thunderbird.1000.xxxx.lz4
Message: Process 7282 (thunderbird) of user 1000 dumped core.

Stack trace of thread 7282:
#0 0x00007f22d3cbfdc9 raise (libpthread.so.0)
#1 0x00007f22d0a52a1b n/a (libxul.so)
#2 0x00007f22d1246419 n/a (libxul.so)
#3 0x00007f22d3cbfef0 __restore_rt (libpthread.so.0)
#4 0x00007f22d0dff101 n/a (libxul.so)
#5 0x00007f22d4086162 n/a (n/a)

[…]
[…]
gdb-peda$ backtrace
#0 0x00007f22d3cbfdc9 in raise () from /usr/lib/libpthread.so.0
#1 0x00007f22d0a52a1b in ?? () from /usr/lib/thunderbird/libxul.so
#2 0x00007f22d1246419 in ?? () from /usr/lib/thunderbird/libxul.so
#3 <signal handler called>
#4 0x00007f22d0dff101 in ?? () from /usr/lib/thunderbird/libxul.so
#5 0x00007f22d4086162 in ?? ()
#6 0x00007f22d4086680 in ?? ()
#7 0x00007ffcf067fb58 in ?? ()
#8 0x00007ffcf0680020 in ?? ()
#9 0x00007ffcf067fb60 in ?? ()
#10 0x41e0000800400000 in ?? ()
#11 0x00007f22d408a862 in ?? ()
#12 0x00007f2200000000 in ?? ()
#13 0x00007ffcf067fb88 in ?? ()
#14 0x0000000000000d00 in ?? ()
#15 0x00007f22d27acfc0 in ?? () from /usr/lib/thunderbird/libxul.so
#16 0x00007f22b6457250 in ?? ()
#17 0x00007f22b03a9dd0 in ?? ()
#18 0x0000000000000900 in ?? ()
#19 0x41e0000800400000 in ?? ()
#20 0xfffc7f229fd14940 in ?? ()
#21 0xfffc7f22971696a0 in ?? ()
#22 0x0000000000000000 in ?? ()
Comment by Alad Wenter (Alad) - Sunday, 15 May 2016, 11:41 GMT
That stack trace is useless unless you recompile it with debug symbols.

https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces
Comment by Jan Alexander Steffens (heftig) - Sunday, 15 May 2016, 11:49 GMT
Does it work if you edit your prefs.js and add the following?

user_pref("javascript.options.ion", false);
Comment by Muflone (muflone) - Sunday, 15 May 2016, 11:54 GMT
@heftig
after adding the preference javascript.options.ion" = false, it works fine for me
Comment by Stefano (senden9) - Sunday, 15 May 2016, 12:00 GMT
With this option it works also fine for me. So do we need a stack trace from a debug build anyway or is this now unnecessary?
Comment by Jan Alexander Steffens (heftig) - Sunday, 15 May 2016, 12:01 GMT
I just need to make a new release that sets this option by default.

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

Loading...