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

Bug#695865: marked as done (SIGSEGV in libcdio)

Your message dated Mon, 20 Nov 2017 22:22:55 +0100
with message-id <5fbd8b50-ce98-5fe4-0e1c-e54f2f26aa0d@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 owner@bugs.debian.org
immediately.)


-- 
695865: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695865
Debian Bug Tracking System
Contact owner@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 00007f43efeff880 sp 00007f43edc69788 error 4 in libc-2.13.so[7f43efe7f000+180000]

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  0x00007fd085c85af8 in cdtext_data_init (p_user_data=0x1c9df80, i_first_track=1 '\001', wdata=0x7fd08253c820  <incomplete sequence \322>, i_data=162, 
        set_cdtext_field_fn=0x7fd085c83d79 <set_cdtext_field_generic>) at cdtext.c:298
    #2  0x00007fd085c960d7 in mmc_init_cdtext_private (p_user_data=0x1c9df80, run_mmc_cmd=0x7fd085c89556 <run_mmc_cmd_linux>, 
        set_cdtext_field_fn=0x7fd085c83d79 <set_cdtext_field_generic>) at mmc/mmc.c:384
    #3  0x00007fd085c83e77 in init_cdtext_generic (p_env=0x1c9df80) at _cdio_generic.c:452
    #4  0x00007fd085c839f5 in get_cdtext_generic (p_user_data=0x1c9df80, i_track=0 '\000') at _cdio_generic.c:278
    #5  0x00007fd085c8538d in cdio_get_cdtext (obj=0x1c98400, i_track=0 '\000') at cdio.c:69
    #6  0x0000000000403a0e in fetch_metadata (cdda_backend=0x1c90850) at gvfsbackendcdda.c:179
    #7  0x000000000040402b in do_mount (backend=0x1c90850, job=0x1c899b0, mount_spec=0x1c8c190, mount_source=0x1c90180, is_automount=0) at gvfsbackendcdda.c:447
    #8  0x00007fd08686c7d3 in run (job=0x1c899b0) at gvfsjobmount.c:116
    #9  0x00007fd08686b4d4 in g_vfs_job_run (job=0x1c899b0) at gvfsjob.c:197
    #10 0x00007fd086863a78 in job_handler_callback (data=0x1c899b0, user_data=0x1c88020) at gvfsdaemon.c:184
    #11 0x00007fd085593e88 in g_thread_pool_thread_proxy (data=<optimized out>) at /build/buildd-glib2.0_2.34.3-1-amd64-aLhxnS/glib2.0-2.34.3/./glib/gthreadpool.c:309
    #12 0x00007fd085593605 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 0x00007fd085310b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
    #14 0x00007fd08505aa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
    #15 0x0000000000000000 in ?? ()
    (gdb) frame 1
    #1  0x00007fd085c85af8 in cdtext_data_init (p_user_data=0x1c9df80, i_first_track=1 '\001', wdata=0x7fd08253c820  <incomplete sequence \322>, i_data=162,
        set_cdtext_field_fn=0x7fd085c83d79 <set_cdtext_field_generic>) 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 <rocky@gnu.org>
    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 argument
        3) Language, Genre, Genre Code and Encoding Fields are now properly parsed and stored in the cdtext object
        4) Added public function cdio_get_cdtext_raw to extract the binary CD-Text
        5) Added CDTEXTFILE keyword logic in cue sheet parser. Parses binary/raw CD-Text files
        6) Added cdtext_genre2str to convert genre code
        7) altered the example programs, test drivers, cdda-player and cd-info to work with these changes
        8) Added test case
        9) A few smaller changes
        A disc either holds CD-Text for all the tracks or does not hold any. Therefore a CD-Text object for the whole disc seems more natural to me. It also enables us to store global fields, like genre, encoding, language.
        
        Patch was tested on GNU/Linux 32 bit running Gentoo.

This is good enough for me; you might like to add that to the Debian
package as-is, or instead analyze and fix the bug alone instead of
backporting that whole refactoring patch.  (I'm available for testing any
patches.)


Grüße,
 Thomas

Attachment: pgp1fHf54aiD2.pgp
Description: PGP signature


--- End Message ---
--- Begin Message --- 
Version: 0.92-2

On Fri, 29 Sep 2017 17:11:39 +0200 Thomas Schwinge
<thomas@codesourcery.com> wrote:
> After installing the Debian experimantal 0.92-2+b1 libcdio-dev and
> libcdio15:amd64 packages, I then rebuilt the Debian testing gvfs packages
> against that one (no source code changes required).  This resolves the
> issue for me.

So I close the issue with the right meta information. This has recently
been rolled out in testing as well.

Paul

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
Reply to: