* [ISSUE] firefox i686 segfaults on startup
@ 2022-09-30 9:13 thamesynne
2022-09-30 9:35 ` thamesynne
` (18 more replies)
0 siblings, 19 replies; 20+ messages in thread
From: thamesynne @ 2022-09-30 9:13 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
New issue by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538
Description:
### Is this a new report?
Yes
### System Info
Void 5.18.16_1 i686 GenuineIntel uptodate rFFFF, Void 5.18.19_1 i686 AuthenticAMD uptodate F
### Package(s) Affected
firefox-105.0_1
### Does a report exist for this bug with the project's home (upstream) and/or another distro?
_No response_
### Expected behaviour
firefox starts up as normal
### Actual behaviour
firefox immediately crashes with a segmentation fault, even before it gets to the processing of --help (let alone --safe-mode).
The last 2 lines of strace before the Killed notification are
```
mmap2(0xf7901000, 1044480, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7901000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xfffff0b3} ---
```
(I had to uninstall it before I could capture the full strace output, as i needed a working browser to report this issue).
### Steps to reproduce
```
$ sudo xbps-install -u firefox
$ firefox --help
Segmentation fault
```
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
@ 2022-09-30 9:35 ` thamesynne
2022-09-30 11:12 ` Duncaen
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: thamesynne @ 2022-09-30 9:35 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 11772 bytes --]
New comment by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263341756
Comment:
I just went back to get the full output of strace, and here it is:
```
execve("/usr/bin/firefox", ["firefox", "--help"], 0xbf9d16f4 /* 35 vars */) = 0
brk(NULL) = 0x5c7000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef3000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/firefox/tls/i686/sse2/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/firefox/tls/i686/sse2", 0xbff040d0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/firefox/tls/i686/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/firefox/tls/i686", 0xbff040d0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/firefox/tls/sse2/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/firefox/tls/sse2", 0xbff040d0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/firefox/tls/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/firefox/tls", 0xbff040d0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/firefox/i686/sse2/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/firefox/i686/sse2", 0xbff040d0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/firefox/i686/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/firefox/i686", 0xbff040d0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/firefox/sse2/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/firefox/sse2", 0xbff040d0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/firefox/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/firefox", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=46262, ...}) = 0
mmap2(NULL, 46262, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ee7000
close(3) = 0
openat(AT_FDCWD, "/usr/lib32/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0m\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1106636, ...}) = 0
mmap2(NULL, 131328, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ec6000
mmap2(0xb7ecc000, 73728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0xb7ecc000
mmap2(0xb7ede000, 20480, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0xb7ede000
mmap2(0xb7ee3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0xb7ee3000
mmap2(0xb7ee5000, 4352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ee5000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/firefox/libdl.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/libdl.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\21\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=143480, ...}) = 0
mmap2(NULL, 20532, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ec0000
mmap2(0xb7ec1000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xb7ec1000
mmap2(0xb7ec3000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0xb7ec3000
mmap2(0xb7ec4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0xb7ec4000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/firefox/libatomic.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/tls/i686/sse2/libatomic.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib32/tls/i686/sse2", 0xbff04090) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/tls/i686/libatomic.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib32/tls/i686", 0xbff04090) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/tls/sse2/libatomic.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib32/tls/sse2", 0xbff04090) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/tls/libatomic.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib32/tls", 0xbff04090) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/i686/sse2/libatomic.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib32/i686/sse2", 0xbff04090) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/i686/libatomic.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib32/i686", 0xbff04090) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/sse2/libatomic.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib32/sse2", 0xbff04090) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/libatomic.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300 \0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=30148, ...}) = 0
mmap2(NULL, 36964, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7eb6000
mmap2(0xb7eb8000, 12288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0xb7eb8000
mmap2(0xb7ebb000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0xb7ebb000
mmap2(0xb7ebd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0xb7ebd000
mmap2(0xb7ebf000, 100, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ebf000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/firefox/libstdc++.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/libstdc++.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \301\7\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=2562728, ...}) = 0
mmap2(NULL, 2574584, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c00000
mmap2(0xb7c78000, 1384448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x78000) = 0xb7c78000
mmap2(0xb7dca000, 647168, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ca000) = 0xb7dca000
mmap2(0xb7e68000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x267000) = 0xb7e68000
mmap2(0xb7e73000, 6392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7e73000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/firefox/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\301\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=3241580, ...}) = 0
mmap2(NULL, 1032208, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7b03000
mprotect(0xb7b0f000, 978944, PROT_NONE) = 0
mmap2(0xb7b0f000, 802816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0xb7b0f000
mmap2(0xb7bd3000, 172032, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd0000) = 0xb7bd3000
mmap2(0xb7bfe000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xfa000) = 0xb7bfe000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/firefox/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\"\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=124504, ...}) = 0
mmap2(NULL, 127560, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e96000
mmap2(0xb7e98000, 98304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0xb7e98000
mmap2(0xb7eb0000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0xb7eb0000
mmap2(0xb7eb4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d000) = 0xb7eb4000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/firefox/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib32/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\360\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=11853920, ...}) = 0
mmap2(NULL, 2023128, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7915000
mprotect(0xb7932000, 1880064, PROT_NONE) = 0
mmap2(0xb7932000, 1536000, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d000) = 0xb7932000
mmap2(0xb7aa9000, 339968, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x194000) = 0xb7aa9000
mmap2(0xb7afd000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0xb7afd000
mmap2(0xb7b01000, 7896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7b01000
close(3) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e94000
set_thread_area({entry_number=-1, base_addr=0xb7e94dc0, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=6)
mprotect(0xb7afd000, 8192, PROT_READ) = 0
mprotect(0xb7eb4000, 4096, PROT_READ) = 0
mprotect(0xb7bfe000, 4096, PROT_READ) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e92000
mprotect(0xb7e68000, 28672, PROT_READ) = 0
mprotect(0xb7ee3000, 4096, PROT_READ) = 0
mprotect(0xb7ebd000, 4096, PROT_READ) = 0
mprotect(0xb7ec4000, 4096, PROT_READ) = 0
mprotect(0x4de000, 8192, PROT_READ) = 0
mprotect(0xb7f27000, 4096, PROT_READ) = 0
munmap(0xb7ee7000, 46262) = 0
set_tid_address(0xb7e94e28) = 24234
set_robust_list(0xb7e94e30, 12) = 0
rt_sigaction(SIGRTMIN, {sa_handler=0xb7ecc6a0, sa_mask=[], sa_flags=SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0xb7ecc750, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
ugetrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sysname="Linux", nodename="amber", ...}) = 0
mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7815000
munmap(0xb7815000, 1048576) = 0
mmap2(NULL, 2093056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7716000
munmap(0xb7716000, 958464) = 0
munmap(0xb7900000, 86016) = 0
mmap2(0xb7801000, 1044480, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7801000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xfffff0b3} ---
+++ killed by SIGSEGV +++
```
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
2022-09-30 9:35 ` thamesynne
@ 2022-09-30 11:12 ` Duncaen
2022-09-30 11:25 ` thamesynne
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Duncaen @ 2022-09-30 11:12 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
New comment by Duncaen on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263440722
Comment:
The strace is not really helpful and we can't build firefox for i686 with debug symbols because of address space limitations.
Maybe a gdb backtrace would help, but without symbols its a bit unlikely.
Did previous versions work for you and does your cpu support SSE2?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
2022-09-30 9:35 ` thamesynne
2022-09-30 11:12 ` Duncaen
@ 2022-09-30 11:25 ` thamesynne
2022-09-30 11:27 ` thamesynne
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: thamesynne @ 2022-09-30 11:25 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
New comment by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263451931
Comment:
Yes (I upgraded from Firefox 104.1, i think?) and yes (the CPUs are an Intel Core i3-2100 and an AMD GX-415GA - Sandy Bridge and Jaguar respectively).
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (2 preceding siblings ...)
2022-09-30 11:25 ` thamesynne
@ 2022-09-30 11:27 ` thamesynne
2022-09-30 11:37 ` q66
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: thamesynne @ 2022-09-30 11:27 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
New comment by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263451931
Comment:
Yes (I upgraded from Firefox 104.1, i think?) and yes (the CPUs are an Intel Core i3-2100 and an AMD GX-415GA - Sandy Bridge and Jaguar respectively).
I wish I could give you more helpful information, but it's crashing so early in its startup process (before even initialising graphics - as I say, not even `firefox --help` run) that I doubt there's much information available anyway.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (3 preceding siblings ...)
2022-09-30 11:27 ` thamesynne
@ 2022-09-30 11:37 ` q66
2022-09-30 12:19 ` thamesynne
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: q66 @ 2022-09-30 11:37 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 174 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263462538
Comment:
why don't you use a 64-bit system?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (4 preceding siblings ...)
2022-09-30 11:37 ` q66
@ 2022-09-30 12:19 ` thamesynne
2022-09-30 12:28 ` thamesynne
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: thamesynne @ 2022-09-30 12:19 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 181 bytes --]
New comment by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263500621
Comment:
If I did, would that fix this bug?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (5 preceding siblings ...)
2022-09-30 12:19 ` thamesynne
@ 2022-09-30 12:28 ` thamesynne
2022-09-30 13:03 ` q66
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: thamesynne @ 2022-09-30 12:28 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
New comment by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263500621
Comment:
If I did, would that fix this bug?
*edit*: In point of fact, this isn't a 32-bit issue. I tried installing firefox on an armv7l-musl system I had to hand (a Raspberry Pi 2), and it works exactly as I'd expect it to.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (6 preceding siblings ...)
2022-09-30 12:28 ` thamesynne
@ 2022-09-30 13:03 ` q66
2022-09-30 13:15 ` thamesynne
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: q66 @ 2022-09-30 13:03 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263548861
Comment:
considering firefox works just fine on x86_64, yes, it would fix the problem for you
your hardware is fully x86_64 capable and there are no benefits to running a 32-bit system on it (it will just be slower)
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (7 preceding siblings ...)
2022-09-30 13:03 ` q66
@ 2022-09-30 13:15 ` thamesynne
2022-09-30 13:20 ` thamesynne
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: thamesynne @ 2022-09-30 13:15 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
New comment by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263561823
Comment:
You've clearly never tried using 64-bit Firefox on a system booting from a USB key, with 4GB RAM.
I have, which is why I don't do that any more. It reliably freezes up whichever machine I try it on; Firefox claims 28GB space for itself, which is all very well until it decides it's going to try and use it all.
32-bit Firefox, for obvious reasons, doesn't do that. So even on my 64-bit systems, I run 32-bit Firefox in a chroot.
Now, rather than telling me how I've spent the last three decades using my machines all wrong, how about you *actually try fixing the bug I have reported*? Or if you have no interest in doing that, how about simply keeping your own counsel and not doing your level best to reduce the Void userbase by one?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (8 preceding siblings ...)
2022-09-30 13:15 ` thamesynne
@ 2022-09-30 13:20 ` thamesynne
2022-09-30 13:44 ` q66
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: thamesynne @ 2022-09-30 13:20 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
New comment by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263561823
Comment:
You've clearly never tried using 64-bit Firefox on a system booting from a USB key, with 4GB RAM.
I have, which is why I don't do that any more. It reliably freezes up whichever machine I try it on; Firefox claims 28GB space for itself, which is all very well until it decides it's going to try and use it all.
32-bit Firefox, for obvious reasons, doesn't do that. So even on my 64-bit systems, I run 32-bit Firefox in a chroot.
Furthermore, I humbly submit that telling someone who reports a bug in an ostensibly supported package that they should stop using that package, rather than actually investigating the bug, might be rather counterproductive.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (9 preceding siblings ...)
2022-09-30 13:20 ` thamesynne
@ 2022-09-30 13:44 ` q66
2022-09-30 13:59 ` thamesynne
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: q66 @ 2022-09-30 13:44 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 306 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263596113
Comment:
i have done exactly that, and i've never seen firefox attempt to claim 28GB of RAM
even right now, with tons of tabs open, firefox's virtual memory usage is ~2.5GB
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (10 preceding siblings ...)
2022-09-30 13:44 ` q66
@ 2022-09-30 13:59 ` thamesynne
2022-09-30 14:08 ` paper42
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: thamesynne @ 2022-09-30 13:59 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
New comment by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263613282
Comment:
I don't know what to tell you, other than that my experience does not match yours.
You're in the position of power here; you're a member of the Void Linux team. I'm just a user.
You could have opted to look into the bug, but instead you chose to attack the person reporting it.
If this is what passes for acceptable in the Void community, I don't think I want to be a part of it any more.
I won't be engaging with this issue any further. Fix it, don't fix it, whatever. I've moved back to firefox-esr for now. And you can be sure that I won't be reporting any more issues to Void.
Maybe that's what you intended? I have no idea. If so, then well done. If not, then... yeah.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (11 preceding siblings ...)
2022-09-30 13:59 ` thamesynne
@ 2022-09-30 14:08 ` paper42
2022-09-30 14:29 ` q66
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: paper42 @ 2022-09-30 14:08 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 206 bytes --]
New comment by paper42 on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263625482
Comment:
I don't see anyone attacking you, but sure. Good bye, I guess.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (12 preceding siblings ...)
2022-09-30 14:08 ` paper42
@ 2022-09-30 14:29 ` q66
2022-09-30 15:15 ` mtboehlke
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: q66 @ 2022-09-30 14:29 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263650449
Comment:
nobody was attacking you
but considering hardly anybody uses i686 nowadays, it's not being tested and the number of issues will only go up over time
which is why it's preferable for people to use 64-bit software if they have a 64-bit computer
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (13 preceding siblings ...)
2022-09-30 14:29 ` q66
@ 2022-09-30 15:15 ` mtboehlke
2022-09-30 15:16 ` q66
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: mtboehlke @ 2022-09-30 15:15 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
New comment by mtboehlke on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263704159
Comment:
So... I am one of those few still using i686 on a device. You know what they say, the cheapest laptop is the one you have. Seeing this issue I upgraded and also am getting segmentation fault on attempting to start Firefox. I can also say 104 worked for me and my processor does support SSE2.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (14 preceding siblings ...)
2022-09-30 15:15 ` mtboehlke
@ 2022-09-30 15:16 ` q66
2022-09-30 15:17 ` q66
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: q66 @ 2022-09-30 15:16 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263706284
Comment:
it seems the issue is a fallout of the switch to clang in 105, so i686 might get reverted back to gcc
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (15 preceding siblings ...)
2022-09-30 15:16 ` q66
@ 2022-09-30 15:17 ` q66
2022-09-30 15:57 ` mtboehlke
2022-09-30 21:36 ` [ISSUE] [CLOSED] " Duncaen
18 siblings, 0 replies; 20+ messages in thread
From: q66 @ 2022-09-30 15:17 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263706284
Comment:
it seems the issue is a fallout of the switch to clang in 105, so i686 might get reverted back to gcc (yet another reason to use 64-bit build if possible: much better performance under clang due to skia's simd code being heavily clang-reliant)
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (16 preceding siblings ...)
2022-09-30 15:17 ` q66
@ 2022-09-30 15:57 ` mtboehlke
2022-09-30 21:36 ` [ISSUE] [CLOSED] " Duncaen
18 siblings, 0 replies; 20+ messages in thread
From: mtboehlke @ 2022-09-30 15:57 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
New comment by mtboehlke on void-packages repository
https://github.com/void-linux/void-packages/issues/39538#issuecomment-1263704159
Comment:
So... I am one of those few still using an i686 device. You know what they say, the cheapest laptop is the one you have. Seeing this issue I upgraded and also am getting segmentation fault on attempting to start Firefox. I can also say 104 worked for me and my processor does support SSE2.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ISSUE] [CLOSED] firefox i686 segfaults on startup
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
` (17 preceding siblings ...)
2022-09-30 15:57 ` mtboehlke
@ 2022-09-30 21:36 ` Duncaen
18 siblings, 0 replies; 20+ messages in thread
From: Duncaen @ 2022-09-30 21:36 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]
Closed issue by thamesynne on void-packages repository
https://github.com/void-linux/void-packages/issues/39538
Description:
### Is this a new report?
Yes
### System Info
Void 5.18.16_1 i686 GenuineIntel uptodate rFFFF, Void 5.18.19_1 i686 AuthenticAMD uptodate F
### Package(s) Affected
firefox-105.0_1
### Does a report exist for this bug with the project's home (upstream) and/or another distro?
Not as far as I can tell.
### Expected behaviour
firefox starts up as normal
### Actual behaviour
firefox immediately crashes with a segmentation fault, even before it gets to the processing of --help (let alone --safe-mode).
The last 2 lines of strace before the Killed notification are
```
mmap2(0xf7901000, 1044480, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7901000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xfffff0b3} ---
```
(I had to uninstall it before I could capture the full strace output, as i needed a working browser to report this issue).
If I had to guess, I'd suspect a library issue?
### Steps to reproduce
```
$ sudo xbps-install -u firefox
$ firefox --help
Segmentation fault
```
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2022-09-30 21:36 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-30 9:13 [ISSUE] firefox i686 segfaults on startup thamesynne
2022-09-30 9:35 ` thamesynne
2022-09-30 11:12 ` Duncaen
2022-09-30 11:25 ` thamesynne
2022-09-30 11:27 ` thamesynne
2022-09-30 11:37 ` q66
2022-09-30 12:19 ` thamesynne
2022-09-30 12:28 ` thamesynne
2022-09-30 13:03 ` q66
2022-09-30 13:15 ` thamesynne
2022-09-30 13:20 ` thamesynne
2022-09-30 13:44 ` q66
2022-09-30 13:59 ` thamesynne
2022-09-30 14:08 ` paper42
2022-09-30 14:29 ` q66
2022-09-30 15:15 ` mtboehlke
2022-09-30 15:16 ` q66
2022-09-30 15:17 ` q66
2022-09-30 15:57 ` mtboehlke
2022-09-30 21:36 ` [ISSUE] [CLOSED] " Duncaen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).