Ubuntu
xfburn package

xfburn crash when creating adding files to new composition

Bug #61579 reported by hotsauce
30
This bug affects 2 people
Affects Status Importance Assigned to Milestone
xfburn (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: xfburn

on xubuntu-desktop edgy knot 3, updated since the release

I can drag n drop files but not use the add button

1- Open xfburn
2- New compliation button
3- Add button
4- program crashes

terminal output:

** Message: Using Thunar-VFS 0.3.3
** Message: looking for device [1]
** Message: device [1] found : GCR-8523B (/dev/hdd)
** Message: device [1] capabilities :
** Message: looking for device [2]
** Message: device [2] found : HL-DT-ST GCE-8525B (/dev/hdc)
** Message: device [2] capabilities : CD-R CD-RW
** Message: looking for device [3]
** Message: Requested device index [3] is out of bounds. All devices have been read.

(xfburn:11688): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()

(xfburn:11688): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()

(xfburn:11688): Gtk-CRITICAL **: gtk_tree_store_get_value: assertion `VALID_ITER (iter, tree_store)' failed

(xfburn:11688): GLib-GObject-WARNING **: gtype.c:3337: type id `0' is invalid

(xfburn:11688): GLib-GObject-WARNING **: can't peek value table for type `<invalid>' which is not currently referenced
Segmentation fault (core dumped)

Revision history for this message
In , Jani Monoses (jani) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier:

UI becomes unresponsive and eventually crashes when pressing Add after selecting a new compilation
Here's a report against 0.2.0 but I checked and it's the same for svn head.
https://launchpad.net/distros/ubuntu/+source/xfburn/+bug/61579

Reproducible: Always

Steps to Reproduce:
1.startx xfburn
2.select new composition
3.select add

Revision history for this message
In , Jean-François Wauthy (pollux-xfce) wrote :

i have seen that problem during development but i couldn't find why, i'll try to look deeper and understand what's happening

Revision history for this message
In , Gauvain Pocentek (gpocentek) wrote :

From what I can understand, the $HOME directory is the value stored in the selected_files variable, so the Add button tries to add the whole user directory if no other file have been selected after cliking the "new compisition" button.

Bug Watch Updater (bug-watch-updater)
Changed in xfce:
status: Unknown → In Progress
John Vivirito (gnomefreak)
Changed in xfburn:
status: Unconfirmed → Confirmed
Revision history for this message
In , Jani Monoses (jani) wrote :

The directory browser (left pane) is defaulted to ~/ so a default Add will add the home dir recursively which takes a lot of time or causes crashes elsewhere because of the memory usage.

Revision history for this message
In , Jean-François Wauthy (pollux-xfce) wrote :

(In reply to comment #3)
> The directory browser (left pane) is defaulted to ~/ so a default Add will add
> the home dir recursively which takes a lot of time or causes crashes elsewhere
> because of the memory usage.
>

I'm aware of the problem i just haven't the time to fix it currently. And i don't think the problem is related to some memory usage, because if you deselect the home dir then select it again and try to add it... it works (at least i remember it worked)

Revision history for this message
In , Jani Monoses (jani) wrote :

> I'm aware of the problem i just haven't the time to fix it currently. And i
> don't think the problem is related to some memory usage, because if you
> deselect the home dir then select it again and try to add it... it works (at
> least i remember it worked)

I tried deselecting and then reselecting but get the same. By memory usage I mean it tries to read in thw whole ~ which may be tens of GB as in my case.

When adding is done via an explicit file chooser dialog it is much less likely this can occur as users would rarely want to add their whole home-dir to the compilation.

Revision history for this message
Jani Monoses (jani) wrote :

as a workaround make sure the selection in the left pane is not on your home dir. The default action for add is to add whetever that is and if you have alartge home it chokes on it.

Revision history for this message
Gerd Bavendiek (gerd-bavendiek) wrote :

Same problem here. I tried the workaround, but it did not work for me:

lulu:/home/bav> xfburn
** Message: Using Thunar-VFS 0.3.3
** Message: looking for device [1]
** Message: device [1] found : UJDA760 DVD/CDRW (/dev/hdc)
** Message: device [1] capabilities : CD-R CD-RW
** Message: looking for device [2]
** Message: Requested device index [2] is out of bounds. All devices have been read.

** (xfburn:17841): WARNING **: unable to open directory : Error opening directory '/home/bav/.gxine/socket': Not a directory

(xfburn:17841): Gtk-CRITICAL **: gtk_tree_store_get_value: assertion `VALID_ITER (iter, tree_store)' failed

(xfburn:17841): GLib-GObject-WARNING **: gtype.c:3337: type id `0' is invalid

(xfburn:17841): GLib-GObject-WARNING **: can't peek value table for type `<invalid>' which is not currently referenced
Segmentation fault (core dumped)

core file is avail, but running gdb on my site seems not to make sense, because /usr/bin/xfburn is stripped.

Is there anything I can do to help ?

Gerd

Revision history for this message
In , Jeromeg (jeromeg) wrote :

This is still happening in Ubuntu Feisty with xfburn 0.2.0-0ubuntu2, any news on this ?

Revision history for this message
In , Jean-François Wauthy (pollux-xfce) wrote :

i'm still slowly working on 0.3.0, but i haven't looked into it yet.

Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

This still happens in Feisty, marking as triaged.

Changed in xfburn:
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
In , Mario Đanić (mario-danic) wrote :

Thank you for your bug report. Can you still reproduce the problem with svn?

Revision history for this message
In , Jeromeg (jeromeg) wrote :

I can still reproduce this with revision 4539 of trunk.

I think I can try to give more details :

It seems to happen for top level directories such as home, file system... and also for directories which contain only folders. If something is selected in the right column (file/size/type), it never crashes, whatever directory is selected in the left column.

A solution could be to always automatically select the first item of the file/size/type column ?

Bug Watch Updater (bug-watch-updater)
Changed in xfce:
status: In Progress → Confirmed
Revision history for this message
Daniel T Chen (crimsun) wrote :

Is this symptom still reproducible in 8.10 alpha?

Changed in xfburn:
status: Triaged → Incomplete
Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

Not reproducible with xfburn 0.3.2.

Changed in xfburn:
status: Incomplete → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in xfce:
importance: Unknown → Medium
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

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