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