thunar crashed with SIGSEGV in magazine_chain_pop_head()

Bug #1203296 reported by Doug Fisherman on 2013-07-20
394
This bug affects 90 people
Affects Status Importance Assigned to Milestone
GTK+
Fix Released
Medium
gtk+2.0 (Ubuntu)
High
Unassigned
thunar (Ubuntu)
Medium
Alistair Buxton

Bug Description

I didn't notice a crash, just the crash reporting alert for no apparant reason.
Perhaps something in background I am unaware of.

ProblemType: Crash
DistroRelease: Ubuntu 13.10
Package: thunar 1.6.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.10.0-4.13-generic 3.10.1
Uname: Linux 3.10.0-4-generic x86_64
ApportVersion: 2.11-0ubuntu1
Architecture: amd64
CrashCounter: 1
Date: Sat Jul 20 08:47:00 2013
ExecutablePath: /usr/bin/thunar
InstallationDate: Installed on 2013-07-19 (0 days ago)
InstallationMedia: Xubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130717)
MarkForUpload: True
ProcCmdline: /usr/bin/Thunar /media/username/Data/Downloads/torrents/complete/Flood.2007.DVDRip.XviD-VoMiT
ProcEnviron:
 LANGUAGE=en_CA:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SegvAnalysis:
 Segfault happened at: 0x7f4cf7099069: mov 0x8(%rax),%rdi
 PC (0x7f4cf7099069) ok
 source "0x8(%rax)" (0x00000008) not located in a known VMA region (needed readable region)!
 destination "%rdi" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: thunar
StacktraceTop:
 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 g_slice_free1 () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 g_type_free_instance () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 gtk_tree_view_remove_column () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
Title: thunar crashed with SIGSEGV in g_slice_free1()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo

StacktraceTop:
 magazine_chain_pop_head (magazine_chunks=<synthetic pointer>) at /build/buildd/glib2.0-2.37.3/./glib/gslice.c:550
 magazine_chain_prepare_fields (magazine_chunks=0x0) at /build/buildd/glib2.0-2.37.3/./glib/gslice.c:623
 magazine_cache_push_magazine (ix=11, magazine_chunks=0x7f4cfad84900, count=8) at /build/buildd/glib2.0-2.37.3/./glib/gslice.c:697
 thread_memory_magazine2_unload (ix=<optimized out>, tmem=<optimized out>) at /build/buildd/glib2.0-2.37.3/./glib/gslice.c:815
 g_slice_free1 (mem_size=<optimized out>, mem_block=0x7f4cfaba7700) at /build/buildd/glib2.0-2.37.3/./glib/gslice.c:1106

Changed in thunar (Ubuntu):
importance: Undecided → Medium
summary: - thunar crashed with SIGSEGV in g_slice_free1()
+ thunar crashed with SIGSEGV in magazine_chain_pop_head()
tags: removed: need-amd64-retrace
Launchpad Janitor (janitor) wrote :

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

Changed in thunar (Ubuntu):
status: New → Confirmed

Thunar crashes now and then with a segmentation fault.

Steps to Reproduce:
1) Start thunar.
2) Wait.

No specific action is required for thunar to crash. I just have to wait a few minutes and thunar crashes.

Output in console says "Segmentation fault (core dumped)", there is no core file though. Executing generate-core-file in gdb outputs "Couldn't get registers: No such process."
Output of "bt full" in gdb:

#0 0x00007ffff4bca887 in g_slice_alloc () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#1 0x00007ffff4bcad5e in g_slice_alloc0 () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#2 0x00007ffff4bad244 in g_source_new () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#3 0x00007ffff4bb00a9 in g_timeout_source_new () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#4 0x00007ffff510a4c2 in ?? () from /usr/lib/libgio-2.0.so.0
No symbol table info available.
#5 0x00007ffff4bafdf3 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#6 0x00007ffff4baf296 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#7 0x00007ffff4baf5e8 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#8 0x00007ffff4baf9ea in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#9 0x00007ffff6a3b9d7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#10 0x0000000000424262 in main (argc=1, argv=0x7fffffffe538) at main.c:310
        session_client = 0xc84b40
        dbus_service = 0x0
        application = 0x7e76c0
        error = 0x0
        working_directory = 0x7f5820 "XSMP"
        filenames = 0x7f59e0
        startup_id = 0x0

Any help getting more detailed debug info would be appreciated. Thunar version 1.6.3git-fc4a4b6 crashes as well.

tags: added: trusty
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/1203296

tags: added: package-qa-testing
Jackson Doak (noskcaj) on 2014-02-23
information type: Private → Public

We are seeing this type of crash reported several hundred times per day in Xubuntu with the automatic error reporting. However, you seem to be the only person who can reproduce it reliably. It is crashing inside the glib memory allocator which indicates random memory corruption in a totally different part of the code, and seems to give many different types of crash.

Please install debugging symbols for glib and gtk to get the missing symbols filled in, then redo the stack trace.

Then please run it in valgrind like this:

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --num-callers=40 --track-origins=yes --log-file=valgrind.log thunar

And then attach valgrind.log. It will run really slow, don't worry about that.

Also is there anything unusual about the way you're running thunar? Are you leaving it open on a directory where the files are constantly changing? strace may also be useful, to see what activity it is doing leading up to the crash.

Another thing to try is:

G_SLICE=debug-blocks gdb thunar

tags: added: bugpattern-needed

I was about to investigate this further today, but (un?)fortunately the random crashing has stopped. Suddenly everything's fine.

Somehow I'm feeling unsatisfied now.

Elfy (elfy) wrote :

Plugged in Sansa mp3 player.

Recognised, did some media player movement.

Unmounted and ejected - thunar crashed.

Changed in thunar (Ubuntu):
assignee: nobody → Alistair Buxton (a-j-buxton)

Crashing has started again.

The crashing has started again.
However I'm unable to attach any logs, I get logged out by the site repeatedly.

Created attachment 5406
GDB trace log

Created attachment 5407
Valgrind log

Thunar did not crash when running with valgrind. I just quit thunar and attached the log anyway, as it may still be helpful.

These logs are no use out of context.

How did you run it? How did it crash? What signal was received?

Couldn't you just read my initial bug report? Everything necessary should be in there.

GDB log created with "gdb thunar", in gdb console "r". I ran valgrind just the way you told me to. Crash is a segmentation fault.
That's it, or did I miss something?

Are you saying that the crash is reproducable but NOT if you run it with the valgrind command? Or did it just crash once and now you can't reproduce it at all?

Please try the command from comment 3.

I can reproduce it, the crash occurs usually within 10 seconds to two minutes. I ran it with valgrind for ~10 minutes, then gave up.

Somehow I missed your comment 3, sorry. I'll attach a new log.

Created attachment 5408
G_SLICE=debug-blocks gdb thunar

Created attachment 5409
G_SLICE=debug-blocks gdb thunar

That is really weird. Everything is consistent with memory corruption caused by mismatch between memory allocators - forcing it to always use malloc prevents the crash.

But your last log crashes while allocating. G_SLICE=debug-blocks should cause a crash on deallocation.

Please let me know if I can help any further.

b3nmore (b3nmore) wrote :

Attached a gdb backtrace from running:
G_SLICE=debug-blocks gdb --args Thunar --daemon

To reproduce quite reliably, I have to open a thunar window, mount/umount e.g. usb drives or network shares, browse some local folders and close thunar (some times looping through the whole procedure several times). But in the end thunar always segfaults at /build/buildd/glib2.0-2.40.0/./glib/gslice.c:544.

b3nmore (b3nmore) wrote :

backtrace like in the previous comment, but for all threads.

Robert Ancell (robert-ancell) wrote :
Alistair Buxton (a-j-buxton) wrote :

Yes, we know. Unfortunately it is completely unreproducible - it seems different for everyone. On top of that, all the traces are useless because it is crashing inside the Gtk slice allocator which means the corruption happened much earlier - or this is a Gtk bug.

I think it is actually responsible for something like 9 out of the top 10 crashes in Xubuntu, and I have yet to find anyone who's steps to reproduce work on my machine.

There's also an upstream bug report but there's nothing useful there either.

Changed in thunar:
importance: Undecided → Unknown
status: New → Unknown
Alistair Buxton (a-j-buxton) wrote :

The upstream report does have one interesting factor: the steps to reproduce are "run thunar and wait 2 minutes" which is rather unique. All the other methods I've seen basically amount to "use thunar until it crashes."

Changed in thunar:
importance: Unknown → Medium
status: Unknown → Confirmed
b3nmore (b3nmore) wrote :

I believe I found a reliable way to reproduce the crash:
- open thunar
- use the side panel to mount a usb stick (or use automount)
- open a document on the usb volume (e.g. a pdf file)
- keep it open and try to unmount the usb stick via the side pane
- cancel the window which informs that the volume is busy
- close the document
- unmount the volume
- close the thunar window
 -> thunar segfaults

Some remarks: If a thunar --daemon instance is running all other thunar instances will quit when one produces a segfault.
If no thunar --daemon is running other thunar instances then the one which segfaults may survive (especially if they were started before the segfaulting one).

Okay, this works. You must right click -> unmount, not not click the
eject icon which does not cause the crash.

On 5 May 2014 17:35, b3nmore <email address hidden> wrote:
> I believe I found a reliable way to reproduce the crash:
> - open thunar
> - use the side panel to mount a usb stick (or use automount)
> - open a document on the usb volume (e.g. a pdf file)
> - keep it open and try to unmount the usb stick via the side pane
> - cancel the window which informs that the volume is busy
> - close the document
> - unmount the volume
> - close the thunar window
> -> thunar segfaults
>
> Some remarks: If a thunar --daemon instance is running all other thunar instances will quit when one produces a segfault.
> If no thunar --daemon is running other thunar instances then the one which segfaults may survive (especially if they were started before the segfaulting one).
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1203296
>
> Title:
> thunar crashed with SIGSEGV in magazine_chain_pop_head()
>
> Status in Thunar file manager:
> Confirmed
> Status in “thunar” package in Ubuntu:
> Confirmed
>
> Bug description:
> I didn't notice a crash, just the crash reporting alert for no apparant reason.
> Perhaps something in background I am unaware of.
>
> ProblemType: Crash
> DistroRelease: Ubuntu 13.10
> Package: thunar 1.6.2-0ubuntu1
> ProcVersionSignature: Ubuntu 3.10.0-4.13-generic 3.10.1
> Uname: Linux 3.10.0-4-generic x86_64
> ApportVersion: 2.11-0ubuntu1
> Architecture: amd64
> CrashCounter: 1
> Date: Sat Jul 20 08:47:00 2013
> ExecutablePath: /usr/bin/thunar
> InstallationDate: Installed on 2013-07-19 (0 days ago)
> InstallationMedia: Xubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130717)
> MarkForUpload: True
> ProcCmdline: /usr/bin/Thunar /media/username/Data/Downloads/torrents/complete/Flood.2007.DVDRip.XviD-VoMiT
> ProcEnviron:
> LANGUAGE=en_CA:en
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_CA.UTF-8
> SHELL=/bin/bash
> SegvAnalysis:
> Segfault happened at: 0x7f4cf7099069: mov 0x8(%rax),%rdi
> PC (0x7f4cf7099069) ok
> source "0x8(%rax)" (0x00000008) not located in a known VMA region (needed readable region)!
> destination "%rdi" ok
> SegvReason: reading NULL VMA
> Signal: 11
> SourcePackage: thunar
> StacktraceTop:
> ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> g_slice_free1 () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> g_type_free_instance () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> gtk_tree_view_remove_column () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
> Title: thunar crashed with SIGSEGV in g_slice_free1()
> UpgradeStatus: No upgrade log present (probably fresh install)
> UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/thunar/+bug/1203296/+subscriptions

--
Alistair Buxton
<email address hidden>

Alistair Buxton (a-j-buxton) wrote :

Refined steps to reproduce:

1. move thunar binary to an unpathed directory, to prevent any daemon mode shenanegans by init.
2. gdb ./thunar
3. mount a drive in the sidebar. any type of drive will work. (USB and fixed SATA partitions tested.)
4. open a file on the drive in a program that will lock the file. mousepad doesn't work for this. image viewer does though.
5. attempt to unmount the drive:
  a. right click the drive in the side bar
  b. click on "unmount"
  c. you'll see two busy dialogs. cancel both.
6. Do step 5 again. Sometimes the crash doesn't happen if you only do it once.
7. Close the open file.
8. Attempt to unmount the drive again, as in step 5. This time, it should succeed. "Okay" any dialogs. They don't always appear, but this does not seem to matter.
9. Close the thunar window.

Here is a video of me doing all that:

https://www.youtube.com/watch?v=Lz1haetybhc

One thing of note is that the first time you do step 5, the blue highlight on the sidebar jumps to home, but the second time it stays on the drive. When thunar crashes that drive is still highlighted, but the main file area shows files in home.

Alistair Buxton (a-j-buxton) wrote :

I've tested with G_SLICE=always-malloc and the crash still happens. This rules out crashing due to slice/malloc mismatch, which was the leading theory on the cause of this. Also G_SLICE=debug-blocks didn't crash any earlier, so no help there.

Alistair Buxton (a-j-buxton) wrote :

This is really strange. All I have to do to crash it is mount and unmount a device a multiple of three times. So mount/unmount 3 times, or 6 times, or 9 times etc. Any other number of cycles and it doesn't crash.

Alistair Buxton (a-j-buxton) wrote :

This is a bug in Gtk which has recently been fixed in Gtk3. Of course Thunar uses Gtk2...

Changed in thunar (Ubuntu):
status: Confirmed → Invalid
Changed in thunar:
importance: Medium → Undecided
status: Confirmed → New
Changed in gtk:
importance: Unknown → Medium
status: Unknown → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in gtk+2.0 (Ubuntu):
status: New → Confirmed
no longer affects: thunar
Changed in gtk+2.0 (Ubuntu):
importance: Undecided → High
status: Confirmed → In Progress
Alistair Buxton (a-j-buxton) wrote :
Changed in thunar (Ubuntu):
status: Invalid → Fix Released
Changed in gtk+2.0 (Ubuntu):
status: In Progress → Fix Released
superkuh (n-ubunt1-u) wrote :

I do not believe this bug is fully fixed. I have the "fixed" version of libgtk2.0 and I am still encountering these crashes with alarming regularity. See, https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1372140 for referenced.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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