Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Attempt to run filezilla from application menu, did not appear to start.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Attempt to run from command line
* What was the outcome of this action?
Illegal instruction
* What outcome did you expect instead?
Application start
Kernel ring buffer shows the following:
traps: filezilla[1431] trap invalid opcode ip:b7d934c3 sp:bfcf0480 error:0 in
libfzclient-private-3.63.0.so[b7cb5000+128000]
Hi Andreas,
On Sun, 14 Jul 2024 13:16:02 +0200 Andreas Rönnquist <andreas@ronnquist.net> wrote:
[...]
That's literally all that comes out on the command line:
jon@lapdog:~$ filezilla
Illegal instruction
jon@lapdog:~$
This is on a fairly elderly Celeron laptop running LXQt. I half
wondered if the processor is too old - for info, o/p of /proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Intel(R) Celeron(R) M CPU 420 @ 1.60GHz
stepping : 8
microcode : 0x39
cpu MHz : 1595.938
cache size : 1024 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 tm pbe nx constant_tsc arch_perfmon bts cpuid aperfmperf pni monitor tm2 xtpr pdcm pti dtherm
bugs : cpu_meltdown spectre_v1 spectre_v2 l1tf mds swapgs itlb_multihit mmio_unknown
bogomips : 3191.87
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:
And if it helps, backtrace from gdb:
Program received signal SIGILL, Illegal instruction.
0xb7e804c3 in ?? () from /lib/i386-linux-gnu/libfzclient-private-3.63.0.so
(gdb) bt
#0 0xb7e804c3 in () at /lib/i386-linux-gnu/libfzclient-private-3.63.0.so
#1 0xb7e83c82 in register_options(std::initializer_list<option_def>) ()
at /lib/i386-linux-gnu/libfzclient-private-3.63.0.so
#2 0xb7dede0e in () at /lib/i386-linux-gnu/libfzclient-private-3.63.0.so
#3 0xb7fcfb43 in call_init (env=0xbffff2ac, argv=0xbffff2a4, argc=1, l=<optimized out>) at ./elf/dl-init.c:74
#4 call_init (l=<optimized out>, argc=1, argv=0xbffff2a4, env=0xbffff2ac) at ./elf/dl-init.c:26
#5 0xb7fcfc3b in _dl_init (main_map=<optimized out>, argc=1, argv=0xbffff2a4, env=0xbffff2ac) at ./elf/dl-init.c:121
#6 0xb7fe64f0 in _dl_start_user () at /lib/ld-linux.so.2
Rgs,
Jon.
Thanks for your report - Are you saying that you get "Illegal instruction" when running from the command line? - Could you please provide the full command-line output? Also, which desktop environment are you on? - I have tested on amd64 Xfce and Gnome and cannot reproduce there, and cannot reproduce on i386 Gnome either. /Andreas gusnan@debian.org
On Sun, 14 Jul 2024 12:45:06 +0100 jon bird <jon@onasticksoftware.co.uk> wrote: Thanks - that looks indeed like it might be the problem - however, some debugging would help out to pinpoint it exactly. Thanks - that can be helpful - however, could you please install the debug-symbols for the filezilla packages which would give more information - simplest is probably to get the packages directly here: http://debug.mirrors.debian.org/debian-debug/pool/main/f/filezilla/filezilla-dbgsym_3.63.0-1+deb12u3_i386.deb http://debug.mirrors.debian.org/debian-debug/pool/main/libf/libfilezilla/libfilezilla34-dbgsym_0.41.0-2_i386.deb or you can add the debug repos to your sources.list like described in the wiki here: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols And then install them using apt (filezilla-dbgsym and libfilezilla34-dbgsym). Either of these methods should give a more detailed backtrace which makes it easier to pinpoint the problem. Thank you for your help. /Andreas andreas@ronnquist.net gusnan@debian.org
On Sun, 14 Jul 2024 14:45:33 +0200 Andreas Rönnquist <andreas@ronnquist.net> wrote:
[...]
[...]
Appears to be around here (I also pulled down the source as well):
Program received signal SIGILL, Illegal instruction.
0xb7e804c3 in (anonymous namespace)::get_option_registry () at
./src/engine/optionsbase.cpp:74 74 {
(gdb) list
69 std::vector<option_def> options_;
70 std::map<std::string, size_t, std::less<>>
name_to_option_;
71 };
72
73 std::pair<option_registry&, fz::scoped_lock>
get_option_registry()
74 {
75 static option_registry reg;
76 return std::make_pair(std::ref(reg),
fz::scoped_lock(reg.mtx_));
77 }
78 }
And looks to be sat on a "pinsrd" instruction.
(gdb) disassemble /s
Dump of assembler code for function (anonymous
namespace)::get_option_registry(): Address range 0xb7e804a0 to
0xb7e805ad: ./src/engine/optionsbase.cpp:
74 {
0xb7e804a0 <+0>: push %ebp
0xb7e804a1 <+1>: mov %esp,%ebp
0xb7e804a3 <+3>: push %edi
0xb7e804a4 <+4>: mov %eax,%edi
0xb7e804a6 <+6>: push %esi
0xb7e804a7 <+7>: call 0xb7db5a3d <__x86.get_pc_thunk.si>
0xb7e804ac <+12>: add $0x9abd0,%esi
0xb7e804b2 <+18>: push %ebx
0xb7e804b3 <+19>: sub $0x1c,%esp
0xb7e804b6 <+22>: lea 0x1ca4(%esi),%eax
0xb7e804bc <+28>: movd %eax,%xmm0
0xb7e804c0 <+32>: mov %eax,-0x1c(%ebp)
=> 0xb7e804c3 <+35>: pinsrd $0x1,%eax,%xmm0
0xb7e804c9 <+41>: movq %xmm0,-0x28(%ebp)
Looks to be something that only arrived with SSE4.1. Whereas that dump
of cpuinfo shows that mine only has SSE2. So that answers that one then.
Rgs,
Jon.
It is indeed a problem in the filezilla package - I will investigate it, the sse4.1 requirement seems to have been added as a workaround for some other problem specifically on the i386 architecture, but I will investigate and try to provide a fix. My guess is that it will work just to remove the sse4.1 requirement, but it will need to be tested. best /Andreas
Andreas wrote: Let me know if you want a hand or for me to look over anything: I know a thing or two about GCC, in particular with building cross toolchains with it. Also note that since the build flags are injected in both Bookworm and Trixie/Sid, you'll probably need to work on two fixes. The alleged GCC bug may have been fixed in newer GCC 13 uploads. If that's the case, I can help you bisect to set an appropriate build dependency on a fixed version. If no fixed GCC 13 appears to be packaged, the GCC maintainers could probably apply a patch to Bookworm and Trixie/Sid, and then a tight build dependency would save the day. I'll leave you to doing what you've got to do, but I'm here.
Thank you very much - you can most likely expect to get more mail from me. :) Very much appreciated! best /Andreas
You might have seen the thread I started on debian-devel [1], where they think that this is really a problem in filezilla which should be fixed. From the minor tests I have done, filezilla (without the msse4.1 patch applied) builds fine on gcc-14 on i386 (and all other arches), which however isn't even in unstable yet. I have of course also tested also building with the gcc in unstable (13) on i386 without the patch, and there filezilla doesn't build. The fix in gcc-14 seems to be this: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9a19fa8b616f83474c35cc5b34a3865073ced829 But I of course understand that it most probably is a big investment to get something like this into stable. (oh, why did I adopt this package... ;) /Andreas 1: https://lists.debian.org/debian-devel/2024/07/msg00240.html