[Libburn] New error

Derek Foreman manmower at signalmarketing.com
Mon Aug 23 19:18:30 PDT 2004


On Mon, 23 Aug 2004, Bryan Forbes wrote:

> I moved around my routines like you said, yet I still get a crash.
> Here's the console output and my gdb backtrace:
>
> /
>  AUDIO.CC;1
>  AUDIO.H;1
>  CD_INFO.CC;1
>  CD_INFO.H;1
> [New Thread 81926 (LWP 11478)]
> ignored nwa: 0
>
> ctladr|trno|indx|form|scms|  msf
> ------+----+----+----+----+--------
> 4  1 | 00 | 00 | 01 | 00 |00:00:00
> 4  1 | 01 | 00 | 10 | 00 |00:00:00
> 4  1 | 01 | 01 | 10 | 00 |00:02:00
> 4  1 | AA | 01 | 01 | 00 |00:02:22
> pulling from next track
>
> now, the backtrace (full):
>
> #0  0x0e3ba914 in iso_source_generate (src=0x220, buffer=0x31d1aa70 "",
>    size=2048) at libisofs/writer.c:373
>        next = 0
>        err = BURN_SOURCE_OK
>        target = (struct iso_write_target *) 0x1030d150
> #1  0x0e69ba70 in get_bytes (src=0x1030d198, count=2048, data=0x31d1aa70
> "")
>    at libburn/sector.c:76
>        valid = 0
>        shortage = 2048
>        more = 2048

This is fascinating.  Libisofs appears to return error codes instead of 
data lengths for certain situations, which is somewhat odd.

Especially bad is the return value at end of track, which is a 1.  Since 
you've got libburn set to pull from next track (which should work totally 
fine here), it'll try to grab 2047 more bytes from... an uninitialized 
pointer to 0x220.

If you're feeling adventurous, you wanna test out a quick hack fix for me?

         case ISO_WRITE_DONE:
                 err = BURN_SOURCE_EOF;
                 break;

line 417 in libisofs/writer.c is the err = BURN_SOURCE_EOF;

can you try changing that to err = 0;

and see what happens?


More information about the libburn mailing list