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
>>
>

Reply via email to