[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