g_main_dispatch: assertion failed: (current->dispatching_sources == &current_source_link)

Bug #1205815 reported by Alex_ander on 2013-07-28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
gparted (Ubuntu)

Bug Description

gparted is crashed when i tried umount usb-flash

ProblemType: Crash
DistroRelease: Ubuntu 13.10
Package: gparted 0.16.1-1
ProcVersionSignature: Ubuntu 3.10.0-5.15-generic 3.10.2
Uname: Linux 3.10.0-5-generic i686
ApportVersion: 2.11-0ubuntu1
Architecture: i386
Date: Sun Jul 28 13:15:34 2013
ExecutablePath: /usr/sbin/gpartedbin
InstallationDate: Installed on 2013-07-26 (1 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha i386 (20130726)
MarkForUpload: True
ProcCmdline: /usr/sbin/gpartedbin /dev/sdb
Signal: 6
SourcePackage: gparted
 raise () from /lib/i386-linux-gnu/libc.so.6
 abort () from /lib/i386-linux-gnu/libc.so.6
 ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
 g_assertion_message () from /lib/i386-linux-gnu/libglib-2.0.so.0
 g_assertion_message_expr () from /lib/i386-linux-gnu/libglib-2.0.so.0
Title: gpartedbin crashed with SIGABRT in raise()
UpgradeStatus: No upgrade log present (probably fresh install)

Alex_ander (ks-alexandr) wrote :

 _g_log_abort () at /build/buildd/glib2.0-2.37.3/./glib/gmessages.c:255
 g_assertion_message (domain=domain@entry=0xb6c9746e "GLib", file=file@entry=0xb6c9db84 "/build/buildd/glib2.0-2.37.3/./glib/gmain.c", line=line@entry=3061, func=func@entry=0xb6c9e2dc <__PRETTY_FUNCTION__.11881> "g_main_dispatch", message=0x90b7558 "assertion failed: (current->dispatching_sources == &current_source_link)") at /build/buildd/glib2.0-2.37.3/./glib/gtestutils.c:2075
 g_assertion_message_expr (domain=domain@entry=0xb6c9746e "GLib", file=file@entry=0xb6c9db84 "/build/buildd/glib2.0-2.37.3/./glib/gmain.c", line=3061, func=0xb6c9e2dc <__PRETTY_FUNCTION__.11881> "g_main_dispatch", expr=0xb6c9debc "current->dispatching_sources == &current_source_link") at /build/buildd/glib2.0-2.37.3/./glib/gtestutils.c:2086
 g_main_dispatch (context=0x8f4d920) at /build/buildd/glib2.0-2.37.3/./glib/gmain.c:3061
 g_main_context_dispatch (context=context@entry=0x8f4d920) at /build/buildd/glib2.0-2.37.3/./glib/gmain.c:3634

Changed in gparted (Ubuntu):
importance: Undecided → Medium
summary: - gpartedbin crashed with SIGABRT in raise()
+ gpartedbin crashed with SIGABRT in _g_log_abort()
tags: removed: need-i386-retrace

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

Changed in gparted (Ubuntu):
status: New → Confirmed
Phillip Susi (psusi) on 2013-09-26
summary: - gpartedbin crashed with SIGABRT in _g_log_abort()
+ g_main_dispatch: assertion failed: (current->dispatching_sources ==
+ &current_source_link)
information type: Private → Public
Phillip Susi (psusi) wrote :

I had a thought... those of you who are affected by this, do you have any disks that use 4k sectors? Check with sudo parted -l.

Greg A (etulfetulf) wrote :

Phillip, yes my main disk does.

greg@lmh:~$ sudo parted -l
[sudo] password for greg:
Model: ATA Crucial_CT480M50 (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Phillip Susi (psusi) wrote :

Are you still able to reproduce this crash? I have a test build in my ppa that *might* fix this, so if you can still reproduce it and could try the one in my ppa that would be helpful.

Greg A (etulfetulf) wrote :

Sorry for the delay.

I can't reproduce the crash, but instead when trying to unmount the drive it gets stuck at "Searching /dev/sdb partitions". Even after closing the Gparted window, I am left with three processes:

greg@lmh:~$ ps -A | grep gparted
15719 ? 00:00:00 gparted-pkexec
15720 ? 00:00:00 gparted
15769 ? 00:00:03 gpartedbin

This happens with both the repostitory gparted, and with the verson in your ppa.

Curtis Gedak (gedakc) wrote :

If there are fragmented NTFS or FAT16/32 file systems on a device, then this can cause GParted to take a very long time to scan. This is because the ntfsresize command and the dosfsck command can take a long time to determine used and unused sectors.

One way to check for this issue is with the following command:

   ps -ef | egrep 'ntfsresize|dosfsck'

If this turns out to be the problem, you can work-around the issue by using Windows to dragment these partitions.

Greg A (etulfetulf) wrote :

Thanks for that Curtis. Unfortunately there's no evidence that's the problem.

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

Other bug subscribers