brasero crashed with SIGSEGV in g_type_instance_get_private()

Bug #653630 reported by maik stolle
This bug affects 62 people
Affects Status Importance Assigned to Milestone
brasero (Ubuntu)

Bug Description

Binary package hint: brasero

Steps to reproduce the bug:

1- Open brasero
2- Wait until it's opened
3- Open a second instance of brasero.

It will crash the first instance of it.

ProblemType: Crash
DistroRelease: Ubuntu 10.10
Package: brasero 2.31.92-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic
Uname: Linux 2.6.35-22-generic x86_64
Architecture: amd64
CheckboxSubmission: f18477bfc92e99ef7759f7da094edf63
CheckboxSystem: 2954e74ba17fb0e37fc942cd1d9fab4e
Date: Sat Oct 2 16:56:48 2010
ExecutablePath: /usr/bin/brasero
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta amd64 (20100901.1)
ProcCmdline: brasero /home/username/Downloads/systemrescuecd-x86-1.6.1.iso
 Segfault happened at: 0x7f88fc438411 <g_type_instance_get_private+33>: cmpq $0x0,(%rdi)
 PC (0x7f88fc438411) ok
 source "$0x0" ok
 destination "(%rdi)" (0x4ca74830) not located in a known VMA region (needed writable region)!
SegvReason: writing unknown VMA
Signal: 11
SourcePackage: brasero
 g_type_instance_get_private () from /usr/lib/
 ?? ()
 unique_marshal_ENUM__INT_BOXED_UINT () from /usr/lib/
 g_closure_invoke () from /usr/lib/
 ?? () from /usr/lib/
Title: brasero crashed with SIGSEGV in g_type_instance_get_private()
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Revision history for this message
maik stolle (ms090780) wrote :
Revision history for this message
Apport retracing service (apport) wrote :

 g_type_instance_get_private ()
 brasero_app_finalize (object=0x4ca74830)
 unique_marshal_ENUM__INT_BOXED_UINT (
 g_closure_invoke ()
 ?? () from /usr/lib/

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in brasero (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
visibility: private → public
Revision history for this message
draco (draco31-fr) wrote :

I presume I experiment the same bug.

When I double click on an ISO disk image from nautilus browser in order to burn it, I don't get the brasero dialog box 1 time over 2 exactly. I've got a "waiting" cursor over the nautilus window for a while, and then nothing happen.

The first time I try to open the ISO it is OK. The second time I try to open an ISO (not necessary the same file) I've always got the segfault.

dmesg complain about segfault from brasero due to ; see here :

[446139.533830] brasero[25142]: segfault at 4d55bd4d ip 00007fdcf4d87411 sp 00007fffd6674b30 error 4 in[7fdcf4d5c000+49000]
[446757.727484] brasero[26689]: segfault at 4d55bfb9 ip 00007f17b884d411 sp 00007ffff4b53d70 error 4 in[7f17b8822000+49000]
[446891.378028] brasero[26856]: segfault at 4d55c03f ip 00007f94899a6411 sp 00007fff3880c750 error 4 in[7f948997b000+49000]
[447413.769016] brasero[28339]: segfault at 4d55c24a ip 00007fd596fdb411 sp 00007fff58fcf410 error 4 in[7fd596fb0000+49000]

Obviously, it seems there is no problem when running brasero directly and selecting "burn image".

Changed in brasero (Ubuntu):
status: New → Confirmed
Changed in brasero:
importance: Unknown → Critical
status: Unknown → Incomplete
Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

This sometimes happens to me on a Maverick amd64 system with brasero 2.32.0-0ubuntu2.2 when I right-click on a .iso image file and open it with Brasero. It seems like this happens when I put a CD/DVD in the drive and launch Brasero so that the CD/DVD will be recognized while Brasero is still loading. That is, if I run Brasero immediately after I put the disc in the drive, then usually it will come up and say that I doesn't see the CD (until the CD is recognized). If I put the CD/DVD in the drive and wait, eventually I'll get a dialog box that asks me what to do with the disc. If I wait for this dialog box to be produced and then click Cancel and *then* click Brasero, then Brasero loads without problems and is able to start burning the disc. However, I have not tested this extensively enough to know for sure if this pattern always holds.

Since the above observations may suggest that this bug arises from resource competition, it is perhaps worth mentioning that the system on which I am using Brasero and experiencing this bug has a full GNOME-based environment installed, but that I am in a Lubuntu Desktop Session, which uses the LXDE desktop environment instead of GNOME 2; specifically, it uses PCManFM instead of Nautilus. The pcmanfm package version is 0.9.7-1ubuntu1 and the libfm0/libfm-gtk0 package version is 0.1.12-1ubuntu2. In case it's relevant, my udisks package version is 1.0.1+git20100614-3.

When I first saw this bug, it seemed like it occurred every other time I tried to burn a CD/DVD from an .iso image by right-clicking on the image and launching Brasero. It tended to happen the first time, rather than the second. However, I think that was actually due to the pattern described above--when I inserted a disc into the drive and tried to burn to it, it was still being recognized by other system components (udisks? pcmanfm?), but when I retried, that had finished, and Brasero was able to launch and start the burn.

Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

Since duplicate bug 652984 is with i386, I'll go ahead and add that tag (so it's clear this isn't amd64-only).

tags: added: i386
Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

I'm able to reproduce this bug with brasero 2.32.1-0ubuntu2 on a Natty i386 system (running a standard Unity desktop), and it seems to follow the same pattern I described above.

tags: added: natty
Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

I've just marked bug 742930 as a duplicate of this but, based on comparing the stack traces. That bug had three duplicates of its own which are now duplicates of this bug: bug 753268, bug 753712, and bug 756805. In the (I think) unlikely event that bug 742930 is determined not really to be a duplicate of this bug, those three bugs should be considered to be unmarked as duplicates of this bug too (and perhaps remarked as duplicates of bug 742930).

Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

Correction: "...of this BUG, based on comparing..."

Changed in brasero (Ubuntu):
status: Confirmed → Triaged
description: updated
Changed in brasero:
status: Incomplete → New
Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

While it seems that this bug can be reliably produced by running a second instance of brasero, and I don't disagree with the way the bug description has been changed, I want to emphasize that this bug is not fundamentally *about* multiple instances. Using a mutex to disable multiple instances would prevent that crash, but it would not alleviate the crashing problem for anyone who is affected by this bug over the normal course of using brasero.

Revision history for this message
Stefan (sbossb) wrote :

Happened to me today. I was able to reproduce the bug following the steps.

Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

The upstream bug ( has been marked as a duplicate of upstream bug That bug is RESOLVED with status OBSOLETE, since it is believed not to occur on a GNOME 3 system (developer David King said: "This was probably fixed in the port to GApplication from libunique in Brasero
3.0, so closing as OBSOLETE.")

Is there anyone here who experiences this bug in Oneiric? Running two concurrent instances of Brasero is *not* the only way to produce this crash, and I am wondering if the bug is fixed for the less contrived and actually-important (but less well understood) way in which this bug sometimes occurs. I am guessing it is, but zero work on the natural ways this bug manifests seems to have been done upstream. (Which is not a criticism--perhaps not enough people get this bug without multiple instances for such work to be done.)

Also, is there anyone here who always or usually experiences this bug when running Brasero, on any supported release of Ubuntu (Lucid, Maverick, Natty, or Oneiric, though probably not Oneiric since that has GNOME 3)? If so, then even though this bug will (probably) not be fixed upstream, it would then probably qualify to be fixed as an SRU (see

Changed in brasero:
status: New → Invalid
Mathew Hodson (mhodson)
Changed in brasero:
importance: Critical → Unknown
status: Invalid → Unknown
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.