burn_drive_raw_get_adr segfaults

[pollux]

I'm trying to get xfburn running on my desktop computer and ran into a segfault when burn_drive_get_adr is called.

I'm using libburn 0.3.2.

(gdb) bt full
#0  0xb7284503 in strlen () from /lib/libc.so.6
No symbol table info available.
#1  0xb7ec9668 in burn_drive_raw_get_adr (d=0xb7ee0c54, adr=0x8091534 "") at libburn/drive.c:984
No locals.
#2  0xb7ec9707 in burn_drive_get_adr (drive_info=0x8092174, adr=0x8091534 "") at libburn/drive.c:1001
        ret = 0
#3  0x08057d3f in xfburn_device_list_init () at xfburn-device-list.c:201
        device = <value optimized out>
        ret = <value optimized out>
        drives = (struct burn_drive_info *) 0x8092128
        i = 1
        n_drives = 2
#4  0x080599dd in main (argc=1852404565, argv=0x68542067) at xfburn-main.c:84
        mainwin = <value optimized out>

[pollux]

it appears that d->devname is null in burn_drive_raw_get_adr

[scdbackup]

I'm studying the code of xfburn now:

http://svn.xfce.org/svn/xfce/xfburn/trunk/xfburn/xfburn-device-list.c

There is a mistake at the end of the loop where the drives get evaluated:

  for (i = 0; i < n_drives; i++) {
    [...]
    burn_drive_info_free (&(drives[i])); 
  }

This is twofold illegal:

First

void burn_drive_info_free(struct burn_drive_info drive_infos[]);

is not intended to be called as

burn_drive_info_free (&(drives[i]));

but as

burn_drive_info_free (drives);

(In C &(drives[0]) and drives is the same value. Regrettably the compiler does not recognize my attempt to demand a whole array object and not the address of a single element.)

Second this call is to be issued when the whole burn_drive_info array is not needed any more. So it is illegal to do it within a loop that intends to inspect further drives of the list

---

Remedy proposal:

Edit xfburn-device-list.c and move the offending call out of the loop :

  for (i = 0; i < n_drives; i++) {
    XfburnDevice *device = g_new0 (XfburnDevice, 1);
    [...]
    devices = g_list_append (devices, device);
  }
  burn_drive_info_free(drives);
  burn_finish ();

(One may well omit the call completely because burn_finish() shuts down the library anyway. But that's unclean programming.)

---

If this doesn't help i will have to talk you into making tests with cdrskin and/or libburner.

[pollux]

Replying to scdbackup:

Edit xfburn-device-list.c and move the offending call out of the loop

Ok it has fixed the segfault, thanks for the correction.

[scdbackup]

I'll clarify libburn/libburn.h in that aspect.

I just looked to whom to file a bug report and noticed that its you and that you are already in our CONTRIBUTORS list. :))

Would you be interested to use (and test) our newly gained DVD capabilities ? Either via libburn or via cdrskin.

DVD-R[W] is semantically very near to data CD-R[W]. Just 6 times the size. (The other types might need behavioral adjustment of the frontend because of no multi-session or multi-track capabilities.)

[pollux]

Replying to scdbackup:

Would you be interested to use (and test) our newly gained DVD capabilities ? Either via libburn or via cdrskin.

I'm via libburn but my spare time is really limited currently i'll get to it as soon as i can

DVD-R[W] is semantically very near to data CD-R[W]. Just 6 times the size. (The other types might need behavioral adjustment of the frontend because of no multi-session or multi-track capabilities.)

If i don't use multi-session or multi-track is it the same as for CD-R with libburn ?

[scdbackup]

All supported DVD types (single layer, except DVD+R for now) can do a single data track in pseudo-TAO mode if they are in the right state. I.e. you may set as track source a disk file or stdin, a pipe, a device ...

Single track DVD-R is very near to single track CD-R. You burn once and afterwards it is closed and write protected.

Re-used DVD-RW need to be blanked with fast==0 or else they will need a predicted track size. That's DAO mode which is like single-track CD SAO without multi option.

DVD-RAM, DVD+RW, and formatted Overwriteable DVD-RW are always "blank". I.e. they get no overwrite protection by libburn. A single track is always welcome.

(DVD+R will be even more like CD-R than DVD-R is. No audio, nevertheless.)

Write mode selection has become a science with all those types and multi-capabilities. So there is a new API function

burn_write_opts_auto_write_type()

which does its best to find a write mode. To be applied after the disc was composed from session and track and after all other burn_write_opts are set.

Be invited to test media types with test/libburner which uses this call to decide what write mode to use with what job. It should also refuse nicely on jobs which the media cannot fulfill. (There are so many combinations. Any testing is welcome. If you want to avoid media waste then change the code to keep it from calling burn_disc_write().)

cdrskin has an own decision mess-up yet. Not to be copied, please. :))