[Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)

[George Danchev]

On Thursday 05 July 2012 08:47:15 Thomas Schmitt wrote:
> Hi,

Hi All,

> i am currently the developer of libburn and libisofs.
> 
> > https://bugzilla.gnome.org/show_bug.cgi?id=655601
> 
> I know about such problems, but i do not know how to get into a
> discussion with Brasero developers.
> My impression is that the libisofs plugin causes libisofs to end
> prematurely. libburn is less of a suspect here.
> 
> 
> I have seen burn logs where burning ends after about 50 % of
> the expected output was produced by libisofs. I.e. libisofs would
> want to write more, but for some reason libburn is urged to finish
> burning (or falsely decides that burning is done).
>   https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
>   https://launchpadlibrarian.net/71440716/brasero_log.txt
> 
> have:
> > BraseroLibisofs Finished track successfully
> > BraseroLibisofs disconnecting BraseroLibisofs from BraseroGrowisofs
> > ...
> > BraseroGrowisofs stdout:  3866984448/7761410048 (49.8%) @4.0x, remaining
> > 12:06 RBU  40.9% UBU 100.0% BraseroGrowisofs called
> > brasero_job_get_action
> > BraseroGrowisofs called brasero_job_set_current_action
> > BraseroGrowisofs stderr: /dev/sr0: flushing cache
> > ...
> > BraseroGrowisofs stderr: HUP
> 
> Note that libburn is not involved here. Only libisofs. Burning is done
> via growisofs.
> Further it seems that BraseroLibisofs is the one which decides when
> the connection between both shall end.
> 
> 
> But in
>   http://bugzilla-attachments.gnome.org/attachment.cgi?id=205344
> the work of libisofs seems to get completed.
> 
> > brasero (libisofs)DEBUG : Processed 138390 of 138390 KB (100 %)
> 
> So this might be two different problems.
> (In this run, libburn was indeed in charge of writing to media.)
> 
> 
> ---------------------------------------------------------------------
> 
> I am not aware of any changes in libisofs or libburn which about a year
> ago could have introduced such problems.
> The combination of libisofs and libburn works fine in xorriso.
> xorriso does several backups per day for me, which then get thoroughly
> checked for readability and correct content.
> 
> If somebody shows up who understands the code of the libisofs plugin
> and could make experiments, then i would be glad to help with finding
> the cause of the problem.

Same issue already reported long ago at:
https://mail.gnome.org/archives/brasero-list/2011-July/msg00004.html

actors: libisofs and growisofs brasero plugins
symptoms: 50% finished at ~49% 

Looking at the logs and the brasero plugins code, the main suspect most likely 
hidden at:


1) erroneous read of growisofs std out, wrt written data, and buffer filling, 
hence a premature leave might occur:

plugins/growisofs/burn-growisofs.c
static BraseroBurnResult
brasero_growisofs_read_stdout (BraseroProcess *process, const gchar *line)
{
        int perc_1, perc_2;
        int speed_1, speed_2;
        long long b_written, b_total;

        /* Newer growisofs version have a different line pattern that shows
         * drive buffer filling. */
        if (sscanf (line, "%10lld/%lld (%4d.%1d%%) @%2d.%1dx, remaining %*d:
%*d",
                    &b_written, &b_total, &perc_1, &perc_2, &speed_1, 
&speed_2) == 6) {
                BraseroJobAction action;

                brasero_job_get_action (BRASERO_JOB (process), &action);
                if (action == BRASERO_JOB_ACTION_ERASE && b_written >= 65536) 
{
                        /* we nullified 65536 that's enough. A signal SIGTERM
                         * will be sent in process.c. That's not the best way
                         * to do it but it works. */
                        brasero_job_finished_session (BRASERO_JOB (process));
                        return BRASERO_BURN_OK;
                }


2) premature ending of the libisofs thread:

static gpointer
brasero_libisofs_thread_started (gpointer data) {

...
        if (brasero_job_get_fd_out (BRASERO_JOB (self), NULL) == 
BRASERO_BURN_OK)
                brasero_libisofs_write_image_to_fd_thread (self);
...





Nothing more concrete norrowed down yet

-- 
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>