Darn, I forgot to paste the second part of the screen output... Here is the full Valgrind output again:
$ valgrind --leak-check=full cyanrip -s 6 -N -c 1/2 -U -r 3 ==659486== Memcheck, a memory error detector ==659486== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==659486== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==659486== Command: cyanrip -s 6 -N -c 1/2 -U -r 3 ==659486== Checking /dev/cdrom for cdrom... CDROM sensed: TSSTcorp CDDVDW SH-224FB SB00 SCSI CD-ROM Opening drive... ==659486== Warning: noted but unhandled ioctl 0x5325 with no size/direction hints. ==659486== This could cause spurious value errors to appear. ==659486== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==659486== Invalid read of size 1 ==659486== at 0x4847DC4: strcmp (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==659486== by 0x11D8A5: ??? (in /usr/bin/cyanrip) ==659486== by 0x10F57C: ??? (in /usr/bin/cyanrip) ==659486== by 0x8100C89: (below main) (libc_start_call_main.h:58) ==659486== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==659486== ==659486== ==659486== Process terminating with default action of signal 11 (SIGSEGV) ==659486== Access not within mapped region at address 0x0 ==659486== at 0x4847DC4: strcmp (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==659486== by 0x11D8A5: ??? (in /usr/bin/cyanrip) ==659486== by 0x10F57C: ??? (in /usr/bin/cyanrip) ==659486== by 0x8100C89: (below main) (libc_start_call_main.h:58) ==659486== If you believe this happened as a result of a stack ==659486== overflow in your program's main thread (unlikely but ==659486== possible), you can try to increase the size of the ==659486== main thread stack using the --main-stacksize= flag. ==659486== The main thread stack size used in this run was 8388608. ==659486== ==659486== HEAP SUMMARY: ==659486== in use at exit: 13,140,444 bytes in 3,166 blocks ==659486== total heap usage: 5,891 allocs, 2,725 frees, 13,565,769 bytes allocated ==659486== ==659486== 640 bytes in 1 blocks are possibly lost in loss record 936 of 994 ==659486== at 0x48459F3: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==659486== by 0x40112A2: calloc (rtld-malloc.h:44) ==660597== by 0x40112A2: allocate_dtv (dl-tls.c:370) ==660597== by 0x4011CCD: _dl_allocate_tls (dl-tls.c:629) ==660597== by 0x816399F: allocate_stack (allocatestack.c:429) ==660597== by 0x816399F: pthread_create@@GLIBC_2.34 (pthread_create.c:652) ==660597== by 0x8038013: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== by 0x8022CEB: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== by 0x804B128: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== by 0x808E253: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== by 0x8090E5A: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== by 0x806BEFD: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== by 0x806D445: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== by 0x803C93A: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== ==660597== 4,608 bytes in 2 blocks are possibly lost in loss record 981 of 994 ==660597== at 0x4840808: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==660597== by 0x40046FB: malloc (rtld-malloc.h:56) ==660597== by 0x40046FB: _dlfo_mappings_segment_allocate (dl-find_object.c:217) ==660597== by 0x40046FB: _dl_find_object_update_1 (dl-find_object.c:671) ==660597== by 0x40046FB: _dl_find_object_update (dl-find_object.c:805) ==660597== by 0x400C267: dl_open_worker_begin (dl-open.c:737) ==660597== by 0x4001488: _dl_catch_exception (dl-catch.c:237) ==660597== by 0x400B715: dl_open_worker (dl-open.c:784) ==660597== by 0x4001488: _dl_catch_exception (dl-catch.c:237) ==660597== by 0x400BAE7: _dl_open (dl-open.c:886) ==660597== by 0x822BACC: do_dlopen (dl-libc.c:95) ==660597== by 0x4001488: _dl_catch_exception (dl-catch.c:237) ==660597== by 0x40015AE: _dl_catch_error (dl-catch.c:256) ==660597== by 0x822BA40: dlerror_run (dl-libc.c:45) ==660597== by 0x822BC4E: __libc_dlopen_mode (dl-libc.c:162) ==660597== ==660597== 14,125 (5,288 direct, 8,837 indirect) bytes in 1 blocks are definitely lost in loss record 986 of 994 ==660597== at 0x48459F3: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==660597== by 0x808E7E3: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== by 0x803C73E: curl_easy_init (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0) ==660597== by 0x11D517: ??? (in /usr/bin/cyanrip) ==660597== by 0x10F57C: ??? (in /usr/bin/cyanrip) ==660597== by 0x8100C89: (below main) (libc_start_call_main.h:58) ==660597== ==660597== LEAK SUMMARY: ==660597== definitely lost: 5,288 bytes in 1 blocks ==660597== indirectly lost: 8,837 bytes in 39 blocks ==660597== possibly lost: 5,248 bytes in 3 blocks ==660597== still reachable: 13,119,055 bytes in 3,102 blocks ==660597== suppressed: 0 bytes in 0 blocks ==660597== Reachable blocks (those to which a pointer was found) are not shown. ==660597== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==660597== ==660597== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0) ==660597== ==660597== 1 errors in context 1 of 4: ==660597== Invalid read of size 1 ==660597== at 0x4847DC4: strcmp (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==660597== by 0x11D8A5: ??? (in /usr/bin/cyanrip) ==660597== by 0x10F57C: ??? (in /usr/bin/cyanrip) ==660597== by 0x8100C89: (below main) (libc_start_call_main.h:58) ==660597== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==660597== ==660597== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0) zsh: segmentation fault valgrind -s --leak-check=full cyanrip -s 6 -N -c 1/2 -U -r 3 Thanks and regards. -- Danai On Thu, 13 Jun 2024 at 20:19, Danai SAE-HAN (韓達耐) <da...@debian.org> wrote: > If it's any help, here is the output from Valgrind: > > valgrind --leak-check=full cyanrip -s 6 -N -c 1/2 -U -r 3 > ==659486== Memcheck, a memory error detector > ==659486== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==659486== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright > info > ==659486== Command: cyanrip -s 6 -N -c 1/2 -U -r 3 > ==659486== > Checking /dev/cdrom for cdrom... > CDROM sensed: TSSTcorp CDDVDW SH-224FB SB00 SCSI CD-ROM > > > Opening drive... > ==659486== Warning: noted but unhandled ioctl 0x5325 with no > size/direction hints. > ==659486== This could cause spurious value errors to appear. > ==659486== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing > a proper wrapper. > ==659486== Invalid read of size 1 > ==659486== at 0x4847DC4: strcmp (in > /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) > ==659486== by 0x11D8A5: ??? (in /usr/bin/cyanrip) > ==659486== by 0x10F57C: ??? (in /usr/bin/cyanrip) > ==659486== by 0x8100C89: (below main) (libc_start_call_main.h:58) > ==659486== Address 0x0 is not stack'd, malloc'd or (recently) free'd > ==659486== > ==659486== > ==659486== Process terminating with default action of signal 11 (SIGSEGV) > ==659486== Access not within mapped region at address 0x0 > ==659486== at 0x4847DC4: strcmp (in > /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) > ==659486== by 0x11D8A5: ??? (in /usr/bin/cyanrip) > ==659486== by 0x10F57C: ??? (in /usr/bin/cyanrip) > ==659486== by 0x8100C89: (below main) (libc_start_call_main.h:58) > ==659486== If you believe this happened as a result of a stack > ==659486== overflow in your program's main thread (unlikely but > ==659486== possible), you can try to increase the size of the > ==659486== main thread stack using the --main-stacksize= flag. > ==659486== The main thread stack size used in this run was 8388608. > ==659486== > ==659486== HEAP SUMMARY: > ==659486== in use at exit: 13,140,444 bytes in 3,166 blocks > ==659486== total heap usage: 5,891 allocs, 2,725 frees, 13,565,769 bytes > allocated > ==659486== > ==659486== 640 bytes in 1 blocks are possibly lost in loss record 936 of > 994 > ==659486== at 0x48459F3: calloc (in > /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) > ==659486== by 0x40112A2: calloc (rtld-malloc.h:44) > > > Is this an upstream issue, or a Debian-specific issue? If the former, let > me know so I can raise it on Github. > > Thanks and regards. > > -- > Danai > > > On Mon, 10 Jun 2024 at 22:21, Danai SAE-HAN (韓達耐) <da...@debian.org> > wrote: > >> Package: cyanrip >> Version: 0.9.3.1-1 >> Severity: important >> >> Hi! >> >> When running cyanrip on an amd64 setup ("testing" mainly), I get a >> segmentation fault SIGSEGV(11): >> >> $ cyanrip -s 6 -N -c 1/2 -U -r 3 >> Checking /dev/cdrom for cdrom... >> CDROM sensed: TSSTcorp CDDVDW SH-224FB SB00 SCSI CD-ROM >> >> >> Opening drive... >> zsh: segmentation fault cyanrip -s 6 -N -c 1/2 -U -r 3 >> $ echo $? >> 139 >> >> >> When I have a look at /var/log/kern.log and syslog, I get: >> kernel: cyanrip[3956208]: segfault at 0 ip 00007f6a7e773647 sp >> 00007ffe5fe46368 error 4 in libc.so.6[7f6a7e641000+157000] likely on CPU 10 >> (core 2, socket 0) >> kernel: Code: 48 01 d0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 >> 66 90 c4 41 01 ef ff 89 f8 09 f0 c1 e0 14 3d 00 00 00 f8 0f 87 29 03 00 00 >> <c5> fe 6f 07 c5 fd 74 0e c5 85 74 d0 c5 ed df c9 c5 fd d7 c9 ff c1 >> >> >> Running in gdb, it complains about a missing file "strcmp-avx2.S": >> >> $ gdb cyanrip >> Reading symbols from cyanrip... >> (No debugging symbols found in cyanrip) >> (gdb) run -s 6 -N -c 1/2 -U -r 3 >> Starting program: /usr/bin/cyanrip -s 6 -N -c 1/2 -U -r 3 >> [Thread debugging using libthread_db enabled] >> >> Using host libthread_db library >> "/lib/x86_64-linux-gnu/libthread_db.so.1". >> Checking /dev/cdrom for cdrom... >> CDROM sensed: TSSTcorp CDDVDW SH-224FB SB00 SCSI CD-ROM >> >> >> Opening drive... >> >> [New Thread 0x7fffe6e006c0 (LWP 3942446)] >> [Thread 0x7fffe6e006c0 (LWP 3942446) exited] >> Thread 1 "cyanrip" received signal SIGSEGV, Segmentation fault. >> __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 >> 283 ../sysdeps/x86_64/multiarch/strcmp-avx2.S: No such file or >> directory. >> >> (gdb) bt >> #0 __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 >> #1 0x00005555555698b6 in () >> #2 0x000055555555b585 in () >> #3 0x00007ffff4442c8a in __libc_start_call_main >> (main=main@entry=0x555555559f20, >> argc=argc@entry=9, argv=argv@entry=0x7fffffffdbd8) at >> ../sysdeps/nptl/libc_start_call_main.h:58 >> #4 0x00007ffff4442d45 in __libc_start_main_impl (main=0x555555559f20, >> argc=9, argv=0x7fffffffdbd8, init=<optimized out>, fini=<optimized out>, >> rtld_fini=<optimized out>, stack_end=0x7fffffffdbc8) >> at ../csu/libc-start.c:360 >> #5 0x000055555555d131 in () >> >> >> >> Let me know if you need more info. >> >> >> Cheers >> >> >> -- >> Danai >> >> >> -- System Information: >> Debian Release: trixie/sid >> APT prefers testing >> APT policy: (500, 'testing') >> Architecture: amd64 (x86_64) >> Foreign Architectures: i386 >> >> Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT) >> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, >> TAINT_UNSIGNED_MODULE >> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE >> not set >> Shell: /bin/sh linked to /usr/bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled >> >> Versions of packages cyanrip depends on: >> ii libavcodec60 7:6.1.1-4+b2 >> ii libavfilter9 7:6.1.1-4+b2 >> ii libavformat60 7:6.1.1-4+b2 >> ii libavutil58 7:6.1.1-4+b2 >> hi libc6 2.38-11 >> ii libcdio-cdda2t64 10.2+2.0.2-1 >> ii libcdio-paranoia2t64 10.2+2.0.2-1 >> ii libcdio19t64 2.1.0-4.2 >> ii libcurl4t64 8.8.0-1 >> ii libmusicbrainz5-2 5.1.0+git20150707-10+b1 >> ii libswresample4 7:6.1.1-4+b2 >> >> cyanrip recommends no packages. >> >> cyanrip suggests no packages. >> >> -- no debconf information >> >