Re: [Bug-xorriso] consultation about libburn

[Thomas Schmitt]

Hi,

> I meet the problem if using the
> command:cdrskin dev=/dev/sr0 -msinfo,but using cdrskin -scanbus has
> no problem and there is no problem using command cdrskin -eject to
> eject the CD-ROM.

All these runs send various SCSI commands to the drive, using the
ioctl(SG_IO). You may add option -V to cdrskin, to get a log of the
commands and their replies:

  cdrskin -V ...your.arguments... 2>&1 | tee -i /tmp/cdrskin_scsi.log


Now for the valgrind log:

> ==3668== Invalid read of size 1
> ==3668==    at 0x484C2E0: strip_spaces (drive.c:1205)
> ...
> ==3668==  Address 0x4ae221f is 1 bytes before a block of size 152 alloc'd
> ==3668==    at 0x48324E8: calloc (vg_replace_malloc.c:618)
> ==3668==    by 0x48514FB: burn_drive_scan_sync (drive.c:1413)

Not the cause of the problem, probably, but not ok either.
Looks like a very old bug ... stupid too ... groan ...


Nevertheless, valgrind's implementation of dynamic memory management
runs into the same problem as the normal management:

> valgrind: m_mallocfree.c:277 (mk_plain_bszB): Assertion 'bszB != 0' failed.
> valgrind: This is probably caused by your program erroneously writing past the
> end of a heap block and corrupting heap metadata.  If you fix any
> invalid writes reported by Memcheck, this assertion failure will
> probably go away.

Since we only got reported a bad read operation, it does not
seem probable that cdrskin or libburn caused the problem.

Whatever, we crashed valgrind. That's not easy.
Its report talks about submitting a bug report. But we have all
reason to believe that it is not valgrind's fault.

This part of valgrind's stack looks interesting:

> ==3668==    by 0x486273B: react_on_drive_loss.isra.5 (sg-linux.c:2040)
> ==3668==    by 0x4863097: sg_issue_command (sg-linux.c:2187)

libburn's Linux adapter got a non-recoverable error from
ioctl(SG_IO) and is trying to clean up. This kind of error
indicates a severe transport problem with SCSI command or reply.

So the difference between the two Linuxes might be in a problem
of bus driver, bus hardware, or DVD drive, which then triggers an
unusual code path in the kernel.
Were both Linuxes tested on the same machine ?

It would be interesting to see the SCSI log. See above, option -V.


Have a nice day :)

Thomas