Re: Bug#1121758: dpkg-deb crashing on liblzma5
Hallo,
* Guillem Jover [Wed, Dec 03 2025, 12:20:12PM]:
> > Okay, then I wanted to install one of my existing kernel-image DEBs. And then initramfs build also started crashing.
> >
> > But why? The common factor here was, again, liblzma5!
> >
> > So I have changed the compression type of initramfs to zstd and now it works... somehow. Still not explaining what is happening with liblzma5 here.
>
> I cannot reproduce this problem within liblzma5 (which would seem
> independent from dpkg, that has seen no upload since the release of
> Debian stable).
And this is the weird part which confuses me, this started happening
like out of blue. I have checked my RAM with memtest86, no issues were
found. ATM I start suspecting some influence from the CPU microcode. I
was using an RC kernel after all. But OTOH I have been using it for a
while, then again I have compiled it with CPU specific settings, but it
stitll was working fine, for a while.
But the last observation was that, for example:
make bindeb-pkg -j14 KCFLAGS='-march=x86-64-v3 -mtune=znver3' KDEB_COMPRESS=zstd
worked, but
make bindeb-pkg -j14 KCFLAGS='-march=x86-64-v3 -mtune=znver3' KDEB_COMPRESS=xz
simply failed with the mentioned symptoms.
> > Program received signal SIGPIPE, Broken pipe.
> > Download failed: Das Argument ist ungültig. Continuing without source file ./nptl/./nptl/cancellation.c.
> > __internal_syscall_cancel (a1=a1@entry=6, a2=a2@entry=93824993085744, a3=a3@entry=77, a4=a4@entry=0, a5=a5@entry=0, a6=a6@entry=0, nr=1) at ./nptl/cancellation.c:44
> > warning: 44 ./nptl/cancellation.c: Datei oder Verzeichnis nicht gefunden
> > (gdb) bt
> > #0 __internal_syscall_cancel (a1=a1@entry=6, a2=a2@entry=93824993085744, a3=a3@entry=77, a4=a4@entry=0, a5=a5@entry=0, a6=a6@entry=0, nr=1) at ./nptl/cancellation.c:44
> > #1 0x00007ffff7cde6ad in __syscall_cancel (a1=a1@entry=6, a2=a2@entry=93824993085744, a3=a3@entry=77, a4=a4@entry=0, a5=a5@entry=0, a6=a6@entry=0, nr=1) at ./nptl/cancellation.c:75
> > #2 0x00007ffff7d53936 in __GI___libc_write (fd=fd@entry=6, buf=buf@entry=0x555555624930, nbytes=nbytes@entry=77) at ../sysdeps/unix/sysv/linux/write.c:26
> > #3 0x0000555555563389 in fd_write (fd=fd@entry=6, buf=buf@entry=0x555555624930, len=77) at ../../../lib/dpkg/fdio.c:72
> > #4 0x000055555555a0a7 in file_treewalk_feed (dir=<optimized out>, fd_out=6) at ../../src/deb/build.c:180
> > #5 0x0000555555559e87 in tarball_pack (dir=dir@entry=0x7fffffffe093 "debian/linux-image-6.18.0", tar_filenames_feeder=tar_filenames_feeder@entry=0x55555555a040 <file_treewalk_feed>, options=options@entry=0x7fffffffd650,
> > tar_compress_params=0x555555580010 <compress_params>, fd_out=fd_out@entry=4) at ../../src/deb/build.c:555
> > #6 0x000055555555a5c0 in do_build (argv=<optimized out>) at ../../src/deb/build.c:730
> > #7 0x0000555555559adc in main (argc=<optimized out>, argv=<optimized out>) at ../../src/deb/main.c:321
>
> And this looks like something else completely. Which I cannot
> reproduce either.
Yes, that is why I have been reluctant to report this. I just cannot
pinpoint this to an explicit culprit. My coredumpctl log shows a dozen
of crashes, all but one are from dpkg-deb.
The other coredump was from the call in initramfs, but I cannot reproduce it
today either.
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/xz -6 --quiet --no-warn --no-adjust -T0'.
Program terminated with signal SIGSEGV, Segmentation fault.
Download failed: Das Argument ist ungültig. Continuing without source file ./debian/normal-build/src/liblzma/../../../../src/liblzma/lz/lz_encoder_mf.c.
#0 0x00007f4a85ccee4b in bt_find_func (len_limit=64, pos=8388612, cur=0x7f4a80d79013 "ian/", cur_match=277094, depth=47, son=0x7f4a76fbd010, cyclic_pos=3, cyclic_size=8388609, matches=0x7f4a85a822ec, len_best=3)
at ../../../../src/liblzma/lz/lz_encoder_mf.c:483
warning: 483 ../../../../src/liblzma/lz/lz_encoder_mf.c: Datei oder Verzeichnis nicht gefunden
[Current thread is 1 (Thread 0x7f4a821fd6c0 (LWP 1137543))]
(gdb) bt
#0 0x00007f4a85ccee4b in bt_find_func (len_limit=64, pos=8388612, cur=0x7f4a80d79013 "ian/", cur_match=277094, depth=47, son=0x7f4a76fbd010, cyclic_pos=3, cyclic_size=8388609, matches=0x7f4a85a822ec, len_best=3)
at ../../../../src/liblzma/lz/lz_encoder_mf.c:483
#1 0x00007f4a85ccfc51 in lzma_mf_bt4_find (mf=0x7f4a7c000c88, matches=0x7f4a85a822ec) at ../../../../src/liblzma/lz/lz_encoder_mf.c:721
#2 0x00007f4a85ccf1d7 in lzma_mf_find (mf=mf@entry=0x7f4a7c000c88, count_ptr=count_ptr@entry=0x7f4a821fcbfc, matches=matches@entry=0x7f4a85a822ec) at ../../../../src/liblzma/lz/lz_encoder_mf.c:27
#3 0x00007f4a85cd2b14 in helper1 (coder=0x7f4a85a82010, mf=0x7f4a7c000c88, back_res=0x7f4a821fcc94, len_res=0x7f4a821fcc90, position=3) at ../../../../src/liblzma/lzma/lzma_encoder_optimum_normal.c:281
#4 lzma_lzma_optimum_normal (coder=coder@entry=0x7f4a85a82010, mf=mf@entry=0x7f4a7c000c88, back_res=back_res@entry=0x7f4a821fcc94, len_res=len_res@entry=0x7f4a821fcc90, position=3)
at ../../../../src/liblzma/lzma/lzma_encoder_optimum_normal.c:834
#5 0x00007f4a85cd12ac in lzma_lzma_encode (coder=0x7f4a85a82010, mf=mf@entry=0x7f4a7c000c88, out=out@entry=0x7f4a7c000e06 "", out_pos=out_pos@entry=0x7f4a7c000df0, out_size=out_size@entry=65536, limit=2096879)
at ../../../../src/liblzma/lzma/lzma_encoder.c:376
#6 0x00007f4a85cd85cd in lzma2_encode (coder_ptr=0x7f4a7c000d60, mf=0x7f4a7c000c88, out=0x7f4a839ff050 "", out_pos=0x7f4a821fce88, out_size=25167072) at ../../../../src/liblzma/lzma/lzma2_encoder.c:188
#7 0x00007f4a85cce5c3 in lz_encode (coder_ptr=0x7f4a7c000c60, allocator=0x0, in=0x7f4a821fe010 "debian/", in_pos=0x7f4a821fce90, in_size=16384, out=0x7f4a839ff050 "", out_pos=0x7f4a821fce88, out_size=25167072, action=LZMA_RUN)
at ../../../../src/liblzma/lz/lz_encoder.c:176
#8 0x00007f4a85cc227c in block_encode (coder_ptr=0x7f4a7c000b70, allocator=<optimized out>, in=0x7f4a821fe010 "debian/", in_pos=0x7f4a821fce90, in_size=<optimized out>, out=0x7f4a839ff050 "", out_pos=0x7f4a821fce88, out_size=25167072,
action=LZMA_RUN) at ../../../../src/liblzma/common/block_encoder.c:63
#9 0x00007f4a85cc5907 in worker_encode (thr=0x55c6832e22d0, out_pos=0x7f4a821fce88, state=<optimized out>) at ../../../../src/liblzma/common/stream_encoder_mt.c:294
#10 worker_start (thr_ptr=0x55c6832e22d0) at ../../../../src/liblzma/common/stream_encoder_mt.c:393
#11 0x00007f4a85b54b7b in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#12 0x00007f4a85bd27b8 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
> > NOTE:
> >
> > I am also unable to use dpkg-source (as called from dpkg-build). Getting
> > a similar (same?) failure as with dpkg-deb in the debugger, i.e. not
> > SIGSEGV but SIGPIPE.
>
> If dpkg-source is also failing with SIGPIPE, then I'd say there's something
> going on in your environment.
Maybe, but I cannot pin-point it yet. Nothing from the crash dump looks
offending. But I have not been able to build Debian packages on this
system for some days while running the mentioned kernel, which was kinda
inconvenient.
> As it is I cannot reproduce neither of these issues, so there's not
> much that I can do here.
>
> (Also are you sure your system is good, f.ex. «dpkg -V»?)
I have run debsums already, nothing. "dpkg -V" shows missing files like
the stripped locale files, but nothing looks relevant.
dpkg -V | grep usr.lib
missing /usr/lib/python2.7/dist-packages/nevow/plugins
missing /usr/lib/python3.9
missing /usr/lib/i386-linux-gnu/gtk-3.0
missing /usr/lib/i386-linux-gnu/gtk-3.0/3.0.0
missing /usr/lib/i386-linux-gnu/gtk-2.0
missing /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0
missing /usr/lib/gio
missing /usr/lib/gio/modules
missing /usr/lib/python2.7/dist-packages/axiom/plugins
missing /usr/lib/mesa-diverted
missing /usr/lib/mesa-diverted/i386-linux-gnu
missing /usr/lib/mesa-diverted/x86_64-linux-gnu
missing /usr/lib/libpython2.6_d.so.1.0-gdb.py
missing /usr/lib/python2.7/dist-packages/twisted/plugins
????????? /usr/lib/cups/backend/cups-brf
> So I tried to reproduce your original approach and didn't succeed. It
> built. So was the comptured thread the wrong one?
> Also you mentioned something about reproducing again while creating an
> initramfs. This was also dpkg related?
See above for the observations. I am not sure how to reproduce. Calling
the same command line as in the coredump in the plain environment seems
not to have any trouble.
But anyhow, I have upgraded the system further. The current kernel
6.18-rc7 from experimental, for example. Now the issue is not
reproducible anymore.
Best regards,
Eduard.
Reply to: