Bug#842198: Fwd: Re: Bug#842198: goobox: Crashes when run in VirtualBox

[Andreas Henriksson]

Hello Helge Kreutzmann,

On Wed, Jan 11, 2017 at 10:34:17AM +0100, Helge Kreutzmann wrote:
[...]
> Can you have a look at this bug (#842198) to see why the valid call in
> goobox crashes in brasero?
[...]
> > >----- Forwarded message from Jeremy Bicha <jbicha at ubuntu.com> -----
[....]
> > >>#0  brasero_sense_data_not_ready (err=0x0, sense_data=0x7ffd2c31f2e0 "\360") at scsi-sense-data.c:118

brasero_sense_data_not_ready is called with a NULL err and at
scsi-sense-data.c:118 err is derefenced, thus the segfault.

http://sources.debian.net/src/brasero/3.12.1-4/libbrasero-media/scsi-sense-data.c/?hl=110#L118

Next question is why is it called with a NULL err?

> > >>        res = BRASERO_SCSI_FAILURE
> > >>#1  brasero_sense_data_process (sense_data=sense_data at entry=0x7ffd2c31f2e0 "\360", err=err at entry=0x0) at scsi-sense-data.c:210

... also called with a NULL err.... (later passed down).

http://sources.debian.net/src/brasero/3.12.1-4/libbrasero-media/scsi-sense-data.c/?hl=199#L210

> > >>No locals.
> > >>#2  0x00007fcb58ac5e7b in brasero_scsi_command_issue_sync (command=command at entry=0x555bcefe8950, buffer=buffer at entry=0x0, size=size at entry=0, error=error at entry=0x0) at scsi-sg.c:134

... called with NULL error... (later passed down as err).

http://sources.debian.net/src/brasero/3.12.1-4/libbrasero-media/scsi-sg.c/?hl=103#L134

> > >>        sense_buffer = "\360\000\002\000\000\000\000\n\000\000\000\000:\000\000\000\000\000"
> > >>        transport = {interface_id = 83, dxfer_direction = -3, cmd_len = 6 '\006', mx_sb_len = 19 '\023', iovec_count = 0, dxfer_len = 0, dxferp = 0x0, cmdp = 0x555bcefe8950 "\036", sbp = 0x7ffd2c31f2e0 "\360", timeout = 0, flags = 0, pack_id = 0, usr_ptr = 0x0, status = 2 '\002', masked_status = 1 '\001', msg_status = 0 '\000', sb_len_wr = 18 '\022', host_status = 0, driver_status = 8, resid = 0, duration = 12, info = 1}
> > >>        res = <optimized out>
> > >>        cmd = 0x555bcefe8950
> > >>        __func__ = "brasero_scsi_command_issue_sync"
> > >>#3  0x00007fcb58ac5cff in brasero_sbc_medium_removal (handle=handle at entry=0x555bcef80a20, prevent_removal=prevent_removal at entry=0, error=error at entry=0x0) at scsi-prevent-allow-medium-removal.c:91

... called with NULL error... (later passed down).

http://sources.debian.net/src/brasero/3.12.1-4/libbrasero-media/scsi-prevent-allow-medium-removal.c/?hl=80#L91

> > >>        cdb = 0x555bcefe8950
> > >>        res = <optimized out>
> > >>        __func__ = "brasero_sbc_medium_removal"
> > >>#4  0x00007fcb58ac15eb in brasero_drive_unlock (drive=0x555bcee96de0) at brasero-drive.c:565
[...]

Here we explicitly call brasero_sbc_medium_removal with NULL as the
error argument, see:

http://sources.debian.net/src/brasero/3.12.1-4/libbrasero-media/brasero-drive.c/?hl=546#L565



Either this is wrong or the receivers should all be able to handle
NULL as an argument.

Looking again at the case you're hitting in brasero_sense_data_not_ready
which segfaults it has the comment:

			/* No need to use BRASERO_SCSI_SET_ERRCODE
			 * as this is not necessarily an error */
			*err = BRASERO_SCSI_NO_MEDIUM;

All other cases uses the BRASERO_SCSI_SET_ERRCODE and this
macro does (among other things) "if (err) *err = ....;".
Likely the code not using the macro needs to gain the "if (err)" part.

Would be appreciated if you could rebuild brasero with this change
and verify it fixes the issue you're seeing.

Anyway, I think anyone still using brasero should look for an
alternative. Brasero is basically dead. Using it is generally
discouraged. (Or step up and volunteer to maintain it ofcourse!)

Regards,
Andreas Henriksson