FS#49814 - [firefox] segmentation fault

Attached to Project: Arch Linux
Opened by Andreas Baumann (andreas_baumann) - Thursday, 23 June 2016, 06:01 GMT
Last edited by Jan Alexander Steffens (heftig) - Friday, 12 August 2016, 08:34 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Evangelos Foutras (foutrelis)
Jan Alexander Steffens (heftig)
Architecture i686
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: starting firefox results in Segmentation fault (core dumped), on 32-bit

gdb shows nothing interesting:

Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `firefox'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xb7725d91 in ?? ()
[Current thread is 1 (Thread 0xb7334940 (LWP 954))]
(gdb) bt
#0 0xb7725d91 in ?? ()
#1 0x00000000 in ?? ()
(gdb) q


Additional info:
* package version(s): 47.0-2

Steps to reproduce: start firefox
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Friday, 12 August 2016, 08:34 GMT
Reason for closing:  Works for me
Comment by felix (fstirlitz) - Tuesday, 05 July 2016, 13:40 GMT
Similar problem here; Firefox 47.0.1-1. My traceback is:

(gdb) where
#0 0x00007ffff6e78d23 in __free_in6ai () from /usr/lib/libc.so.6
#1 0x00007ffff6e4abdd in getaddrinfo () from /usr/lib/libc.so.6
#2 0x00007fffe72b0732 in PR_GetAddrInfoByName () from /usr/lib/libnspr4.so
#3 0x00007fffe8bd16bd in ?? () from /usr/lib/firefox/libxul.so
#4 0x00007fffe8bccd7c in ?? () from /usr/lib/firefox/libxul.so
#5 0x00007fffe72bcdcb in ?? () from /usr/lib/libnspr4.so
#6 0x00007ffff7bc3484 in start_thread () from /usr/lib/libpthread.so.0
#7 0x00007ffff6e5d6dd in clone () from /usr/lib/libc.so.6
(gdb) x/10i $rip
=> 0x7ffff6e78d23 <__free_in6ai+115>: movsb %ds:(%rsi),%es:(%rdi)
0x7ffff6e78d24 <__free_in6ai+116>: add %cl,0x29ffff(%rax)
0x7ffff6e78d2a <__free_in6ai+122>: jne 0x7ffff6e78d36 <__free_in6ai+134>
0x7ffff6e78d2c <__free_in6ai+124>: jmp 0x7ffff6e78d50 <__free_in6ai+160>
0x7ffff6e78d2e <__free_in6ai+126>: decl 0x29ca7c(%rip) # 0x7ffff71157b0 <lock>
0x7ffff6e78d34 <__free_in6ai+132>: je 0x7ffff6e78d50 <__free_in6ai+160>
0x7ffff6e78d36 <__free_in6ai+134>: lea 0x29ca73(%rip),%rdi # 0x7ffff71157b0 <lock>
0x7ffff6e78d3d <__free_in6ai+141>: sub $0x80,%rsp
0x7ffff6e78d44 <__free_in6ai+148>: callq 0x7ffff6e69cd0 <__lll_unlock_wake_private>
0x7ffff6e78d49 <__free_in6ai+153>: add $0x80,%rsp
(gdb) print $rsi
$1 = 0
(gdb) print $rdi
$2 = 0

So it's a null pointer dereference.

Sent from my w3m
Comment by Jan Alexander Steffens (heftig) - Tuesday, 05 July 2016, 13:41 GMT
What is the content of /etc/nsswitch.conf ?
Comment by felix (fstirlitz) - Tuesday, 05 July 2016, 13:50 GMT
Funny thing, right after I wrote that comment, the issue seemed to have disappeared. But it didn't really go away. My nsswitch.conf:

$ cat /etc/nsswitch.conf
# Begin /etc/nsswitch.conf

passwd: files
group: files
shadow: files

publickey: files

hosts: files mdns_minimal [NOTFOUND=return] dns mdns myhostname
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

# End /etc/nsswitch.conf
$
Comment by Jan Alexander Steffens (heftig) - Tuesday, 05 July 2016, 13:54 GMT
Does the problem disappear if you remove the mdns config? I.e.:

hosts: files dns myhostname
Comment by felix (fstirlitz) - Tuesday, 05 July 2016, 14:04 GMT
No, it doesn't.

It's apparently actually a glibc bug; I've seen liferea crash with the same traceback, though with the difference that $rdi isn't zero.

(gdb) print/x $rdi
$3 = 0x7f5934000020
(gdb) x/32x $rdi
0x7f5934000020: 0x00000000 0x00000003 0x00000000 0x00000000
0x7f5934000030: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f5934000040: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f5934000050: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f5934000060: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f5934000070: 0x00000000 0x00000000 0x34024480 0x00007f59
0x7f5934000080: 0x3401e300 0x00007f59 0x3400cd00 0x00007f59
0x7f5934000090: 0x3401e300 0x00007f59 0x34002ae0 0x00007f59
Comment by felix (fstirlitz) - Tuesday, 05 July 2016, 14:51 GMT
I can't reproduce the issue after rebooting.
Comment by Andreas Baumann (andreas_baumann) - Tuesday, 05 July 2016, 16:13 GMT
My firefox recovered after removing ~/.mozilla and reinstalling firefox.
Comment by Andreas Baumann (andreas_baumann) - Friday, 12 August 2016, 07:54 GMT
New problems arise:

Inconsistency detected by ld.so: get-dynamic-info.h: 124: elf_get_dynamic_info: Assertion `info[DT_PLTREL]->d_un.d_val == DT_REL || info[DT_PLTREL]->d_un.d_val == DT_RELA' failed!

32-bit only, on 64-bit it works.

firefox version 48.0-2
Comment by Andreas Baumann (andreas_baumann) - Friday, 12 August 2016, 08:02 GMT
I start to think that the SD card, the card reader or the filesystem starts to play tricks with me :-)

I also had a corrupt package:

error: firefox: signature from "Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>" is invalid
:: File /var/cache/pacman/pkg/firefox-48.0-2-i686.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Now it works.
Comment by Jan Alexander Steffens (heftig) - Friday, 12 August 2016, 08:34 GMT
Please check your hardware. Run memtest and perhaps use a checksumming filesystem like btrfs.

Loading...