xfburn crashed with SIGSEGV in fill_combo_speed()

Bug #1295721 reported by Volkodav
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
xfburn (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Did not find any burners and crashed on data compilation disc

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: xfburn 0.5.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-18.38-generic 3.13.6
Uname: Linux 3.13.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: XFCE
Date: Fri Mar 21 19:22:06 2014
ExecutablePath: /usr/bin/xfburn
ProcCmdline: xfburn
ProcEnviron:
 LANGUAGE=en_US
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SegvAnalysis:
 Segfault happened at: 0x7f5b0973acc6: mov (%rax),%r15
 PC (0x7f5b0973acc6) ok
 source "(%rax)" (0x8438bf0ae0f208b) not located in a known VMA region (needed readable region)!
 destination "%r15" ok
SegvReason: reading unknown VMA
Signal: 11
SourcePackage: xfburn
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 g_object_new_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
Title: xfburn crashed with SIGSEGV in g_object_new_valist()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare voice

Revision history for this message
Volkodav (vadimtux) wrote :
information type: Private → Public
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 fill_combo_speed (box=box@entry=0x7f5b0a8c5950, device=0x0) at xfburn-device-box.c:470
 refresh_drive_info (box=box@entry=0x7f5b0a8c5950, device=0x0) at xfburn-device-box.c:751
 xfburn_device_box_constructor (type=<optimized out>, n_construct_properties=<optimized out>, construct_properties=<optimized out>) at xfburn-device-box.c:297
 ?? ()
 ?? ()

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceSource.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in xfburn (Ubuntu):
importance: Undecided → Medium
summary: - xfburn crashed with SIGSEGV in g_object_new_valist()
+ xfburn crashed with SIGSEGV in fill_combo_speed()
tags: removed: need-amd64-retrace
Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

https://bugs.launchpad.net/ubuntu/+source/xfburn/+bug/1295721/+attachment/4035991/+files/Stacktrace.txt
> el = 0x8438bf0ae0f208b
> profile_no = 32603

el differs much from all other addresses shown in the stack.
profile_no cannot be originally obtained from libburn.

I'd guess the crash reason is an uninitialized
  GSList *el;
after
  g_object_get (G_OBJECT (xfburn_device_list_get_current_device (priv->devlist)),
                "profile-no", &profile_no,
                "supported-speeds", &el,
                NULL);

> #0 fill_combo_speed (box=box@entry=0x7f5b0a8c5950, device=0x0) at xfburn-device-box.c:470

The value of parameter device stems from
   xfburn_device_list_get_current_device (priv->devlist)
two calls above:

> #2 0x00007f5b0973ba3e in [...] at xfburn-device-box.c:297

So it has to be assumed that this happened in xfburn-device-box.c:436:

  g_object_get (G_OBJECT (NULL),
                "profile-no", &profile_no,
                "supported-speeds", &el,
                NULL);

Regrettably
  http://www.gtk.org/api/2.6/gobject/gobject-The-Base-Object-Type.html#g-object-get
does not specify what happens to &el and &profile in this case.
The stack values indicate that they are random resp. uninitialized.

----------------------------------------------------------------------

The NULL obviously happens because there are no drives detected.
So why that ?

What do you get from

  xorriso -devices

as the user who executes Xfburn, and as superuser ?

What do you get from

  ls -l /dev/sr*

Have a nice day :)

Thomas

Revision history for this message
Volkodav (vadimtux) wrote : Re: [Bug 1295721] Re: xfburn crashed with SIGSEGV in fill_combo_speed()

Well I get brw-rw----+ 1 root cdrom 11, 0 Mar 23 09:42 /dev/sr0 so the
drive is there

On 03/23/2014 01:31 AM, Thomas Schmitt wrote:
> ls -l /dev/sr*

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

> Well I get brw-rw----+ 1 root cdrom 11, 0 Mar 23 09:42 /dev/sr0 so the
> drive is there

So device file non-existence is not the cause.

But meanwhile i was able to produce a nice crash of xfburn after
  chmod a-rw /dev/sr0
and trying to compose an ISO image. At start-up Xfburn warns me
that there is no usable drive.

Valgrind complains about uninitialised values being used.
Among its output is
  Process terminating with default action of signal 11 (SIGSEGV)
  Access not within mapped region at address 0x1
    at 0x417E12: fill_combo_speed (xfburn-device-box.c:453)
which in my xfburn-0.5.1-git version is the same C statement as in
0.5.0's line 470:
    gint write_speed = GPOINTER_TO_INT (el->data);

---------

So the lack of a detected drive seems to be an intermediate cause,
indeed. I will inform the upstream developer now.

---------

Still we do not know why your drive does not get recognised by Xfburn.
The next two suspects would be udev and libburn.

udev should report drive properties by:

  udevadm info --export-db | grep ID_CDROM

libburn can best be exercised by a CLI program

  xorriso -devices

If no drive is found, then direct the SCSI transaction log to a file
/tmp/xorriso_log and post it here:

  xorriso -scsi_log on -report_about all -devices 2>&1 | \
    tee -i /tmp/xorriso_log

If this stays inconclusive, then we would have to start experiments
with the source code of xfburn.
(xfburn/xfburn-device-list.c:get_libburn_device_list around the call
 of burn_drive_scan.)

Have a nice day :)

Thomas

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

one reason for the drive being not recognizable would be
if it was mounted by the operating system.

Does it get visible to Xfburn if you start it after doing
as superuser:

  umount /dev/sr0

Have a nice day :)

Thomas

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

the crash should now be fixed in Xfburn's Git repository.
In a test i was able to create an ISO image file while no burner drive
was accessible.

Packagers interested in a patch will have to combine
  http://git.xfce.org/apps/xfburn/commit/?id=75557169edbb5f499ed97b6bc8708f96f8469d4c
and
  http://git.xfce.org/apps/xfburn/commit/?id=2db1dd16660007102b9168bb4ca71e66753d8877

Nevertheless i assume that Volkodav actually wants to burn an
ISO filesystem to CD or DVD, rather than creating an ISO image
on hard disk.

For that it would be necessary to find out why /dev/sr0 is not
accepted by libburn and how to make it acceptable.
As soon as this is achieved, the bug is of no importance.

Have a nice day :)

Thomas

Revision history for this message
Mantas Kriaučiūnas (mantas) wrote :

New XfBurn version (0.5.2) is released at 2014-04, see
http://git.xfce.org/apps/xfburn/tree/NEWS

xfburn 0.5.2 (2014-04-09)
- Blu-Ray support
- Large file support (iso9660 level 3)
- Small bugfixes
Many thanks to Thomas Schmitt who supplied numerous patches and much debugging help to make this release with BluRay support possible.

Ubuntu 14.04 LTS has older - 0.5.0 release, maybe someone could package new 0.5.2 release to PPA? Please :)

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfburn (Ubuntu):
status: New → Confirmed
Changed in xfburn (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.