* Gabriel F. T. Gomes:
>
> I said this before, but I found this hacky way of doing it to pin-point
> (somewhat) the source of the test failures.

With this hacky setup, where libcdio.so.19 is from version 2.1.0-5, the
segmentation fault is caused by the ABI change, as can be seen in the
following GDB backtrace:

    (gdb) r t/07.iso2.t
    Starting program: /usr/bin/perl t/07.iso2.t
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
    1..5
    # Test ISO9660::IFS routines
    ok 1 - Open CD image ../data/isofs-m1.cue

    Program received signal SIGSEGV, Segmentation fault.
    0xf7b93283 in _fs_stat_root (p_cdio=p_cdio@entry=0x56bf5720) at 
./lib/iso9660/iso9660_fs.c:1066
    warning: 1066   ./lib/iso9660/iso9660_fs.c: No such file or directory
    (gdb) bt
    #0  0xf7b93283 in _fs_stat_root (p_cdio=p_cdio@entry=0x56bf5720) at 
./lib/iso9660/iso9660_fs.c:1066
=>  #1  0xf7b94459 in iso9660_fs_stat (p_cdio=0x56bf5720, psz_path=0xf7b97266 
"/") at ./lib/iso9660/iso9660_fs.c:1364
    #2  0xf7b94a3b in iso9660_fs_readdir (p_cdio=0x56bf5720, 
psz_path=0xf7b97266 "/") at ./lib/iso9660/iso9660_fs.c:1509
    #3  0xf7b94ce2 in find_lsn_recurse (p_image=p_image@entry=0x56bf5720, 
iso9660_readdir=iso9660_readdir@entry=0xf7b949f0 <iso9660_fs_readdir>,
        psz_path=psz_path@entry=0xf7b97266 "/", lsn=26, 
ppsz_full_filename=0xffffda98) at ./lib/iso9660/iso9660_fs.c:1720
    #4  0xf7b95042 in iso9660_fs_find_lsn (p_cdio=0x56bf5720, i_lsn=26) at 
./lib/iso9660/iso9660_fs.c:1804
    #5  0xf7ba5982 in _wrap_fs_find_lsn (my_perl=0x569481a0, cv=0x56b4d460) at 
./perliso9660_wrap.c:3930
    #6  0x566394ea in ?? ()
    #7  0x566c3469 in Perl_runops_standard ()
    #8  0x565a5827 in perl_run ()
    #9  0x56577534 in main ()

Notice how this relates to the data structure that changed and caused
the ABI bump (iso9660_stat_t). This is the same data structure that I
was concerned about in my review, heheheh

Also notice how this is mixing libiso9660 from after the SONAME bump
with the previous version of libcdio(.so.19), which did not have its
SONAME bumped.

I have 2 worries now:

1. Maybe my worries about the ABI break and libdevice-cdio-perl were
not actually too conservative.

2. Why does using an old version of libcdio (not libiso9660) is
causing the issue? Should libcdio's SONAME have been bumped (by
upstream), as well?


There smoke here, even though updating everything at once solves the
problem.

Reply via email to