Your message dated Mon, 20 Nov 2017 22:22:55 +0100
with message-id <5fbd8b50-ce98-5fe4-0e1c-e54f2f26a...@debian.org>
and subject line Re: SIGSEGV in libcdio
has caused the Debian Bug report #695865,
regarding SIGSEGV in libcdio
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
695865: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695865
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libcdio
Version: 0.83-4
Hi!
Upon putting Watain's »Sworn to the Dark« into my CD-ROM drive (bad
omen?), and accessing it (for example, via Rhythmbox or Nautilus), I
reproducibly hit a SIGSEGV in gvfs-backend's gvfsd-cdda, via libcdio:
dmesg:
[107945.344366] pool[24249]: segfault at 7f43f0c5abc0 ip 7f43efeff880
sp 7f43edc69788 error 4 in libc-2.13.so[7f43efe7f000+18]
Pop-up box: »DBus error org.freedesktop.DBus.Error.NoReply: Message did
not receive a reply (timeout by message bus)«.
GDB:
process 19228 is executing new program: /usr/lib/gvfs/gvfsd-cdda
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fd082d3f700 (LWP 19241)]
[New Thread 0x7fd08253e700 (LWP 19243)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fd08253e700 (LWP 19243)]
__strcpy_sse2 () at ../sysdeps/x86_64/multiarch/../strcpy.S:60
60 ../sysdeps/x86_64/multiarch/../strcpy.S: Datei oder Verzeichnis
nicht gefunden.
(gdb) bt
#0 __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/../strcpy.S:60
#1 0x7fd085c85af8 in cdtext_data_init (p_user_data=0x1c9df80,
i_first_track=1 '\001', wdata=0x7fd08253c820 ,
i_data=162,
set_cdtext_field_fn=0x7fd085c83d79 ) at
cdtext.c:298
#2 0x7fd085c960d7 in mmc_init_cdtext_private (p_user_data=0x1c9df80,
run_mmc_cmd=0x7fd085c89556 ,
set_cdtext_field_fn=0x7fd085c83d79 ) at
mmc/mmc.c:384
#3 0x7fd085c83e77 in init_cdtext_generic (p_env=0x1c9df80) at
_cdio_generic.c:452
#4 0x7fd085c839f5 in get_cdtext_generic (p_user_data=0x1c9df80,
i_track=0 '\000') at _cdio_generic.c:278
#5 0x7fd085c8538d in cdio_get_cdtext (obj=0x1c98400, i_track=0 '\000')
at cdio.c:69
#6 0x00403a0e in fetch_metadata (cdda_backend=0x1c90850) at
gvfsbackendcdda.c:179
#7 0x0040402b in do_mount (backend=0x1c90850, job=0x1c899b0,
mount_spec=0x1c8c190, mount_source=0x1c90180, is_automount=0) at
gvfsbackendcdda.c:447
#8 0x7fd08686c7d3 in run (job=0x1c899b0) at gvfsjobmount.c:116
#9 0x7fd08686b4d4 in g_vfs_job_run (job=0x1c899b0) at gvfsjob.c:197
#10 0x7fd086863a78 in job_handler_callback (data=0x1c899b0,
user_data=0x1c88020) at gvfsdaemon.c:184
#11 0x7fd085593e88 in g_thread_pool_thread_proxy (data=)
at
/build/buildd-glib2.0_2.34.3-1-amd64-aLhxnS/glib2.0-2.34.3/./glib/gthreadpool.c:309
#12 0x7fd085593605 in g_thread_proxy (data=0x1c7a6d0) at
/build/buildd-glib2.0_2.34.3-1-amd64-aLhxnS/glib2.0-2.34.3/./glib/gthread.c:797
#13 0x7fd085310b50 in start_thread (arg=) at
pthread_create.c:304
#14 0x7fd08505aa7d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#15 0x in ?? ()
(gdb) frame 1
#1 0x7fd085c85af8 in cdtext_data_init (p_user_data=0x1c9df80,
i_first_track=1 '\001', wdata=0x7fd08253c820 ,
i_data=162,
set_cdtext_field_fn=0x7fd085c83d79 ) at
cdtext.c:298
298 sprintf(buffer,"%s",cdtext_genre[(p_data->text[0] << 8) +
p_data->text[1]]);
(gdb) print cdtext_genre[(p_data->text[0] << 8) + p_data->text[1]]
Cannot access memory at address 0x7fd085d65ca0
(gdb) print p_data->text[0] << 8
$1 = 27648
(gdb) print p_data->text[1]
$2 = 0 '\000'
(gdb) print p_data->text[0]
$3 = 108 'l'
(This is with using the latest, that is, current experimental version of
the gvfs packages; but it reproduces likewise for the current testing
ones.) As I'm not actively interested in understanding and debugging
CD-Text code, I first had a look at upstream libcdio, and it turns out
that if I put the following commit (applies cleanly) on top of Debian's
libcdio package, the error goes away:
commit dbf6d247650e3cae4030f53e5f79fc5d5f094d3f
Author: R. Bernstein
Date: Thu Nov 24 20:54:40 2011 -0500
1) cdtext objects are no longer associated with a track but with the
disc.
2) - cdio_get_cdtext no longer takes track as an argument
- cdtext_get, cdtext_get_const, cdtext_set require track
