[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1070959: /usr/lib/riscv64-linux-gnu/libapt-pkg.so.6.0.0: apt: riscv64: sun20i-d1: http(s): unhandled signal 4 code 0x1 in libapt-pkg.so.6.0.0



Hi,

On Sun, May 12, 2024 at 12:13:11AM +0200, scpcom wrote:
> When I run apt-get update on Allwinner D1 Nezha hardware I get the following errors:
> 
> [ 1610.448999] http[1575]: unhandled signal 4 code 0x1 at 0x0000003fa43ee5f8 in libapt-pkg.so.6.0.0[3fa4326000+19c000]
> [ 1610.459512] CPU: 0 PID: 1575 Comm: http Not tainted 6.6.29+sun20i #sun20i
> [ 1610.466313] Hardware name: Allwinner D1 Nezha (DT)
> [ 1610.471109] epc : 0000003fa43ee5f8 ra : 0000003fa43ee5f8 sp : 0000003fc95c63d0
> [ 1610.478337]  gp : 0000002ae3eca800 tp : 0000003fa35a0780 t0 : 000000000000000a
> [ 1610.485563]  t1 : b8fa9f1e0b81022a t2 : 0000000000000064 s0 : 0000002ae95abe00
> [ 1610.492789]  s1 : 0000000000000000 a0 : 0000002ae95a5f80 a1 : 0000000000000000
> [ 1610.500014]  a2 : 0000002ae9565020 a3 : 0000000000000000 a4 : 0000000000000001
> [ 1610.507239]  a5 : 0000000000000001 a6 : 0000002ae95a1590 a7 : 144ef8bcb0a5ab57
> [ 1610.514465]  s2 : 0000003fa3df9618 s3 : 0000002ae3eca0a0 s4 : ffffffffffffffff
> [ 1610.521691]  s5 : 0000002ae959bda0 s6 : 0000002ae3eca0a0 s7 : 0000003fc95c6d48
> [ 1610.528917]  s8 : 0000003fc95c6d58 s9 : 0000003fc95c6690 s10: 0000002ae9582730
> [ 1610.536144]  s11: 0000003fa44ffd18 t3 : 0000003fa3d167cc t4 : 000000000000003a
> [ 1610.543371]  t5 : 0000000000000001 t6 : 000000000000005c
> [ 1610.548688] status: 0000000200004020 badaddr: 000000008330000f cause: 0000000000000002
> [ 1610.563819] https[1574]: unhandled signal 4 code 0x1 at 0x0000003fa5b155f8 in libapt-pkg.so.6.0.0[3fa5a4d000+19c000]
> [ 1610.574420] CPU: 0 PID: 1574 Comm: https Not tainted 6.6.29+sun20i #sun20i
> [ 1610.581307] Hardware name: Allwinner D1 Nezha (DT)
> [ 1610.586102] epc : 0000003fa5b155f8 ra : 0000003fa5b155f8 sp : 0000003fd7b3b3c0
> [ 1610.593329]  gp : 0000002ac54c6800 tp : 0000003fa4cc6780 t0 : 000000000000000a
> [ 1610.600554]  t1 : b8fa9f1e0b81022a t2 : 0000000000000064 s0 : 0000002ad80d4e40
> [ 1610.607780]  s1 : 0000000000000000 a0 : 0000002ad80cefc0 a1 : 0000000000000000
> [ 1610.615006]  a2 : 0000002ad808e018 a3 : 0000000000000000 a4 : 0000000000000001
> [ 1610.622233]  a5 : 0000000000000001 a6 : 0000002ad80d2bc0 a7 : 6fd82bd679d27ec2
> [ 1610.629458]  s2 : 0000003fa5796618 s3 : 0000002ac54c60a0 s4 : ffffffffffffffff
> [ 1610.636686]  s5 : 0000002ad80d5540 s6 : 0000002ac54c60a0 s7 : 0000003fd7b3bd38
> [ 1610.643912]  s8 : 0000003fd7b3bd48 s9 : 0000003fd7b3b680 s10: 0000002ad80ab730
> [ 1610.651138]  s11: 0000003fa5c26d18 t3 : 0000003fa56b37cc t4 : 000000000000003a
> [ 1610.658363]  t5 : 0000000000000001 t6 : 000000000000005c
> [ 1610.663680] status: 0000000200004020 badaddr: 000000008330000f cause: 0000000000000002
> 
> The problem seems to exists since mid 2023.
> On Ubuntu 23.04 there is no error.
> I got the error on Ubuntu 23.10, 24.04 and latest Debian unstable.
> The error only shows up on the real hardware and not inside a chroot (qemu-user-static riscv64 image on amd64 hardware).
> 
>    * What exactly did you do (or not do) that was effective (or
>      ineffective)?
> 
> I build apt 2.9.2 from sources on Ubuntu 23.04 and installed the resulting libapt-pkg6.0t64 deb on Debian unstable which temporairly solved the problem.
> 
> It looks like a toolchain issue and apt may not be the only affected packge (I have seen the same "unhandled signal 4 code 0x1" on libvte)

This does indeed sound like a toolchain issue given different versions
behave differently and unrelated (to apt) things have the same issue, so
I am "soft-reassigning" this to riscv64 porters in the hope they will
know where to assign and deal with this as libapt seems not a good place
for that as I have quite literally no idea about riscv64…


Installing -dbgsym packages and getting a corefile might be helpful.

I note that you haven't provided much detail on your apt setup,
but given the crash says `http` (and `https`) it might be helpful to
get a simpler reproducer than "ran some apt command":

Do you have the same problem with e.g.:
/usr/lib/apt/apt-helper download-file 'http://example.org/' /tmp/example.html -o Debug::Acquire::http=1
or can you reproduce it with another URI?
One from `apt update --print-uris` perhaps?

If you can, it is possible to talk to `/usr/lib/apt/methods/http`
directly on stdin to might have an easier time debugging this.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


Reply to: