On Sun, 14 Jul 2024 18:59:06 +0100 jon bird <j...@onasticksoftware.co.uk> wrote:
> On Sun, 14 Jul 2024 14:45:33 +0200
> Andreas Rönnquist <andr...@ronnquist.net> wrote:
>
> [...]
> > >>
> > >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:
> >
> > Thanks - that looks indeed like it might be the problem - however,
> > some debugging would help out to pinpoint it exactly.
> > >
> [...]
>
> 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,
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
