Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf
Control: found -1 78.11.0esr-1 Hi Hideki and Jochen, Thank you for both of your responses. On Thu, Jul 01, 2021 at 08:08:44AM +0200, Jochen Sprickerhof wrote: > * Hideki Yamane [2021-06-28 22:35]: > > Can you reproduce it on freshly installed bullseye sytem? After apt upgrade (firefox now at 78.11.0esr-1), the issue is still there. The offending instruction is the same and the backtrace looks very similar. Given that the cause seems well understood (use of NEON instructions on a non-NEON system), I don't think a fresh install would give us any new information. > I only found this reference for NEON on armhf: > > "NEON and VFP/VFP2/VFP3 remain an optional part of the architecture." > > https://wiki.debian.org/ArmHardFloatPort#VFP In addition: "VFPv3-D16 is the common denominator of the processors to support here (therefore the recommended build option is -mfpu=vfpv3-d16)" https://wiki.debian.org/ArmHardFloatPort/VfpComparison#FPU I couldn't find a more authoritative definition of the supported architecture subset for the armhf port. > If this is still reproducible, I see two options: > - Disable NEON code. > - Depend on the neon-support dummy package. Agreed. > > > Kernel: Linux 3.5.7-14-ARCH (PREEMPT) > > It seems that is not the kernel bullseye provides. Correct. The default Debian armhf kernel doesn't give me video, and I forgot whether it even boots. > > And it maybe help to provide its hardware information, too. > The bug author wrote: > > > > This is on a Marvell Dove system, with VFPv3-D16. From /proc/cpuinfo: > > > Features : swp half thumb fastmult vfp edsp iwmmxt thumbee vfpv3 > > > vfpv3d16 tls More specifically, this is on a SolidRun CuBox (first generation, so not the CuBox-i or CuBox-M). I noticed that some time ago, the severity of this bug was raised from normal to serious. While it is serious on my system, I had set it to normal because it likely affects only a relatively small number of systems. And while I would appreciate this bug getting resolved, making it release critical seems unnecessary. Regards, Vincent.
Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf
Package: firefox-esr Version: 78.7.0esr-1 Severity: normal Dear Maintainer, Firefox is killed with SIGILL shortly after startup: $ firefox-esr -safe-mode Illegal instruction $ A gdb session on a dumped core to investigate: [...] Core was generated by `firefox-esr'. Program terminated with signal SIGILL, Illegal instruction. #0 0xaf6f0ab0 in ?? () from /usr/lib/firefox-esr/libxul.so (gdb) backtrace #0 0xaf6f0ab0 in ?? () from /usr/lib/firefox-esr/libxul.so #1 0xb6f32f40 in call_init (l=, argc=argc@entry=1, argv=argv@entry=0xbeb44584, env=env@entry=0xb6a0a240) at dl-init.c:72 #2 0xb6f32fe2 in call_init (env=, argv=, argc=, l=) at dl-init.c:30 #3 _dl_init (main_map=0xb6a30c00, argc=1, argv=0xbeb44584, env=0xb6a0a240) at dl-init.c:119 #4 0xb6cec52e in __GI__dl_catch_exception (exception=exception@entry=0x0, operate=0xb6f352c1 , args=0xbeb41ed8, args@entry=0xbeb41f10) at dl-error-skeleton.c:182 #5 0xb6f35d04 in dl_open_worker (a=) at dl-open.c:758 #6 0xb6cec4f4 in __GI__dl_catch_exception (exception=exception@entry=0xbeb420d8, operate=0xb6f35869 , args=args@entry=0xbeb420e4) at dl-error-skeleton.c:208 #7 0xb6f355cc in _dl_open (file=0xbeb4237c "/usr/lib/firefox-esr/libxul.so", mode=-2147483391, caller_dlopen=0xb6f5df85 <_start+2424>, nsid=-2, argc=1, argv=0xbeb44584, env=0xb6a0a240) at dl-open.c:837 #8 0xb6eeed18 in dlopen_doit (a=0xbeb42344) at dlopen.c:66 #9 0xb6cec4f4 in __GI__dl_catch_exception (exception=exception@entry=0xbeb42300, operate=0xb6eeecc1 , args=args@entry=0xbeb42344) at dl-error-skeleton.c:208 #10 0xb6cec588 in __GI__dl_catch_error (objname=objname@entry=0xb6a0d2ec, errstring=errstring@entry=0xb6a0d2f0, mallocedp=mallocedp@entry=0xb6a0d2e8, operate=, args=args@entry=0xbeb42344) at dl-error-skeleton.c:227 #11 0xb6eef3de in _dlerror_run (operate=, args=args@entry=0xbeb42344) at dlerror.c:170 #12 0xb6eeed9e in __dlopen (file=0xbeb4237c "/usr/lib/firefox-esr/libxul.so", mode=) at dlopen.c:87 #13 0xb6f5df84 in _start () (gdb) layout asm 0xaf6f0ab0 vmov.i32q8, #0 ; 0x This is on a Marvell Dove system, with VFPv3-D16. From /proc/cpuinfo: Features: swp half thumb fastmult vfp edsp iwmmxt thumbee vfpv3 vfpv3d16 tls The referenced (NEON?) register Q8 is not available here, nor even the VFPv3-D32 registers D16-D17 that it maps to. -- Package-specific info: -- Addons package information -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 3.5.7-14-ARCH (PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox-esr depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libatk1.0-0 2.36.0-2 ii libc62.31-9 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.20-1 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-5 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.6-2 ii libgtk-3-0 3.24.24-1 ii libnspr4 2:4.29-1 ii libnss3 2:3.60-1 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.0-2 ii libx11-xcb1 2:1.7.0-2 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxrender1 1:0.9.10-1 ii procps 2:3.3.16-5 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.3.1-8 Versions of packages firefox-esr suggests: pn fonts-lmodern pn fonts-stix | otf-stix pn libcanberra0 ii libgssapi-krb5-2 1.18.3-4 pn libgtk2.0-0 pn pulseaudio -- no debconf information
Bug#693367: w3m: segfaults often on armhf
After upgrading to jessie (and w3m version 0.5.3-19), I have not encountered this issue anymore. All URLs in my bug report now work flawlessly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693367: w3m: segfaults often on armhf
Package: w3m
Version: 0.5.3-8
Severity: important
On my armhf system, w3m segfaults regularly. Whether or not it segfaults
appears to depend reliably on the document being loaded - on some
documents it consistently segfault; on others it consistenly works
flawlessly. For instance, http://www.debian.org or http://www.w3.org are
no problem, whereas http://www.google.com, file:/// or file://. give a
segfault. It does not make a difference if I remove my ~/.w3m directory.
Attached is an strace output from trying to load . (a listing of the
current directory). Please let me know if there's anything I can do to
debug this.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armhf (armv7l)
Kernel: Linux 3.4.0-rc6-13074-ga09b2ce (PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages w3m depends on:
ii libc62.13-35
ii libgc1c2 1:7.1-9
ii libgcc1 1:4.7.2-4
ii libgpm2 1.20.4-6
ii libssl1.0.0 1.0.1c-4
ii libtinfo55.9-10
ii zlib1g 1:1.2.7.dfsg-13
Versions of packages w3m recommends:
ii ca-certificates 20120623
Versions of packages w3m suggests:
ii man-db2.6.2-1
pn menu
pn migemo
ii mime-support 3.52-1
pn w3m-el
pn w3m-img
-- no debconf information
execve("/usr/bin/w3m", ["w3m", "."], [/* 15 vars */]) = 0
brk(0) = 0xb6ff5000
uname({sys="Linux", node="cubox", ...}) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6ed
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=21714, ...}) = 0
mmap2(NULL, 21714, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6eaf000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/arm-linux-gnueabihf/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\3301\0\0004\0\0\0"...,
512) = 512
lseek(3, 401896, SEEK_SET) = 401896
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1160) = 1160
lseek(3, 401560, SEEK_SET) = 401560
read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53
fstat64(3, {st_mode=S_IFREG|0644, st_size=403056, ...}) = 0
mmap2(NULL, 434336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb6e44000
mprotect(0xb6ea6000, 28672, PROT_NONE) = 0
mmap2(0xb6ead000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x61) = 0xb6ead000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/arm-linux-gnueabihf/tls/v7l/vfp/libgc.so.1", O_RDONLY) = -1 ENOENT
(No such file or directory)
stat64("/lib/arm-linux-gnueabihf/tls/v7l/vfp", 0xbe907f00) = -1 ENOENT (No such
file or directory)
open("/lib/arm-linux-gnueabihf/tls/v7l/libgc.so.1", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64("/lib/arm-linux-gnueabihf/tls/v7l", 0xbe907f00) = -1 ENOENT (No such
file or directory)
open("/lib/arm-linux-gnueabihf/tls/vfp/libgc.so.1", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64("/lib/arm-linux-gnueabihf/tls/vfp", 0xbe907f00) = -1 ENOENT (No such
file or directory)
open("/lib/arm-linux-gnueabihf/tls/libgc.so.1", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/lib/arm-linux-gnueabihf/tls", 0xbe907f00) = -1 ENOENT (No such file or
directory)
open("/lib/arm-linux-gnueabihf/v7l/vfp/libgc.so.1", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64("/lib/arm-linux-gnueabihf/v7l/vfp", 0xbe907f00) = -1 ENOENT (No such
file or directory)
open("/lib/arm-linux-gnueabihf/v7l/libgc.so.1", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/lib/arm-linux-gnueabihf/v7l", 0xbe907f00) = -1 ENOENT (No such file or
directory)
open("/lib/arm-linux-gnueabihf/vfp/libgc.so.1", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/lib/arm-linux-gnueabihf/vfp", 0xbe907f00) = -1 ENOENT (No such file or
directory)
open("/lib/arm-linux-gnueabihf/libgc.so.1", O_RDONLY) = -1 ENOENT (No such file
or directory)
stat64("/lib/arm-linux-gnueabihf", {st_mode=S_IFDIR|0755, st_size=12288, ...})
= 0
open("/usr/lib/arm-linux-gnueabihf/tls/v7l/vfp/libgc.so.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/lib/arm-linux-gnueabihf/tls/v7l/vfp", 0xbe907f00) = -1 ENOENT (No
such file or directory)
open("/usr/lib/arm-linux-gnueabihf/tls/v7l/libgc.so.1", O_RDONLY) = -1 ENOENT
(No such file or directory)
stat64("/usr/lib/arm-linux-gnueabihf/tls/v7l", 0xbe907f00) = -1 ENOENT (No such
file or directory)
open("/usr/lib/arm-linux-gnueabihf/tls/vfp/libgc.so.1", O_RDONLY) = -1 ENOENT
(No such file or directory)
st
Bug#673472: gitit: missing dependencies
Package: gitit Version: 0.9.0.1-2 Severity: normal Without mime-support installed, starting gitit results in: Could not read mime types file: /etc/mime.types /etc/mime.types: openBinaryFile: does not exist (No such file or directory) Using defaults instead. Without git installed, starting gitit results in: gitit: Required program 'git' not found in system path. Without libghc-filestore-data installed, starting gitit results in: gitit: /usr/share/filestore-0.4.2/extra/post-update: openBinaryFile: does not exist (No such file or directory) After installing the mentioned packages gitit starts normally, so I suggest to add the following dependencies: Depends: libghc-filestore-data, git | darcs | mercurial Recommends: mime-support -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages gitit depends on: ii libbibutils2 4.12-5 ii libc62.13-32 ii libffi5 3.0.10-3 ii libgmp10 2:5.0.5+dfsg-1.1 ii libjs-jquery 1.7.2-1 ii libjs-jquery-ui 1.8.ooops.20+dfsg-1 ii libpcre3 1:8.30-5 ii zlib1g 1:1.2.7.dfsg-1 gitit recommends no packages. gitit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565451: dokuwiki: postinst script depends on existence of /etc/apache2 directory
Package: dokuwiki
Version: 0.0.20090214b-3
Severity: normal
Tags: patch
Dokuwiki's postinst script normally installs a link in the
/etc/apache2/conf.d directory to its apache.conf. There is some code
to detect the absence of the /etc/apache2 directory and not install
the link in that case, but unfortunately there's a bug. The attached
patch fixes this.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-2-amd64 (SMP w/1 CPU core)
Locale: LANG=C, lc_ctype=nl...@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages dokuwiki depends on:
ii debconf [debconf-2.0]1.5.28 Debian configuration management sy
ii libphp-simplepie 1.2-1 RSS and Atom feed parsing in PHP
ii php-geshi1.0.8.4-1 Generic Syntax Highlighter
ii php5 5.2.11.dfsg.1-2 server-side, HTML-embedded scripti
ii ucf 3.0025 Update Configuration File: preserv
Versions of packages dokuwiki recommends:
ii imagemagick 7:6.5.8.3-1 image manipulation programs
pn php4-cli | php5-cli(no description available)
dokuwiki suggests no packages.
-- debconf information:
* dokuwiki/system/accessible: localhost only
* dokuwiki/webservers:
* dokuwiki/system/documentroot: /wiki
dokuwiki/system/localnet: 10.0.0.0/24
* dokuwiki/system/purgepages: false
--- dokuwiki.postinst.orig 2009-07-13 21:00:04.0 +0200
+++ dokuwiki.postinst 2010-01-15 22:25:26.0 +0100
@@ -76,10 +76,10 @@
{
dir="/etc/apache2"
-echo "Installing into... [$dir]" >/dev/stderr
-
# Skip servers with no configuration
-[ -d $dir ] || continue
+[ -d $dir ] || return 0
+
+echo "Installing into... [$dir]" >/dev/stderr
# Link the apache configuration file to the server's
# conf.d directory
Bug#389896: gdk-imlib11: 'All fallbacks failed' for xbm file
Package: gdk-imlib11
Version: 1.9.14-31
Severity: normal
When trying to view certain .xbm files with qiv, the following error
is reported.
gdk_imlib ERROR: Cannot load image: hand-open-data.xbm
All fallbacks failed.
You should not see this. Submit bug against gdk-imlib package.
One such file is attached. It was taken from the dia package, so in
case of a problem with the attachement, you should be able to reproduce
the problem with:
apt-get source dia
cd dia-0.95.0/app/pixmaps
qiv hand-open-data.xbm
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages gdk-imlib11 depends on:
ii imlib-base 1.9.14-31Common files needed by the Imlib/G
ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries
ii libglib1.2 1.2.10-10.1 The GLib library of C routines
ii libgtk1.2 1.2.10-18The GIMP Toolkit set of widgets fo
ii libjpeg62 6b-13The Independent JPEG Group's JPEG
ii libpng12-0 1.2.8rel-5.2 PNG library - runtime
ii libtiff43.8.2-6 Tag Image File Format (TIFF) libra
ii libungif4g 4.1.4-4 shared library for GIF images
ii libx11-62:1.0.0-9X11 client-side library
ii libxext61:1.0.1-2X11 miscellaneous extension librar
ii libxi6 1:1.0.1-3X11 Input extension library
ii zlib1g 1:1.2.3-13 compression library - runtime
gdk-imlib11 recommends no packages.
-- no debconf information
/* Made with Gimp */
#define hand_open_data_width 20
#define hand_open_data_height 20
static unsigned char hand_open_data_bits[] = {
0xff, 0xff, 0x0f, 0xff, 0xff, 0x0f, 0xff, 0xff, 0x0f, 0xff, 0xf9, 0x0f,
0x9f, 0xc9, 0x0f, 0x9f, 0xc9, 0x0f, 0x3f, 0xc9, 0x0e, 0x3f, 0x49, 0x0e,
0x7f, 0x40, 0x0e, 0x67, 0x00, 0x0e, 0x47, 0x00, 0x0f, 0x0f, 0x00, 0x0f,
0x1f, 0x00, 0x0f, 0x1f, 0x80, 0x0f, 0x3f, 0x80, 0x0f, 0x7f, 0xc0, 0x0f,
0xff, 0xc0, 0x0f, 0xff, 0xc0, 0x0f, 0xff, 0xff, 0x0f, 0xff, 0xff, 0x0f };
Bug#383379: libjpeg-progs: [exifautotran] changes file mode
Package: libjpeg-progs Version: 6b-13 Severity: normal exiftran changes the mode of a file. Even though the original file has mode 0644, the new one has 0600. umask is set to 0022, so that is not the cause of the problem. After reading bug report #376376, I found out about exiftran, and that doesn't have this problem. I agree with the suggestion given there to move exifautotran out of the way. exiftran seems the more robust tool. Thank you. Vincent. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libjpeg-progs depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libjpeg62 6b-13 The Independent JPEG Group's JPEG libjpeg-progs recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298090: cal capitalizes month name
Package: bsdmainutils Version: 5.20020211-4.99 Tags: patch Cal and ncal always capitalize the name of a month. Month names should not be capitalized in every locale, and for those where this is required, strftime already gives a capitalized month name. In Dutch for example, month names are not capitalized, so the following is wrong: $ LANG=nl_NL cal Maart 2005 zo ma di wo do vr za 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 $ I propose to solve this with the following patch. -- cut here -- --- usr.bin/ncal/ncal.c.origFri Mar 4 16:46:52 2005 +++ usr.bin/ncal/ncal.c Fri Mar 4 16:47:35 2005 @@ -610,7 +610,6 @@ #else strftime(mlines->name, sizeof(mlines->name), "%OB", &tm); #endif - mlines->name[0] = toupper((unsigned char)mlines->name[0]); /* * Set first and last to the day number of the first day of this @@ -706,7 +705,6 @@ #else strftime(mlines->name, sizeof(mlines->name), "%OB", &tm); #endif - mlines->name[0] = toupper((unsigned char)mlines->name[0]); /* * Set first and last to the day number of the first day of this -- cut here ---------- Regards, Vincent Arkesteijn. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
