gvfsd-gphoto2 crashed with SIGSEGV in __pthread_mutex_destroy()

Bug #968186 reported by Aspersieman on 2012-03-29
286
This bug affects 176 people
Affects Status Importance Assigned to Milestone
gvfs
Fix Released
High
gvfs (Ubuntu)
High
Martin Pitt
Precise
High
Martin Pitt

Bug Description

I plugged in my Nokia 5800 to import the photos with Shotwell, something I do regularly, and received this bug.

My details:
1) Ubuntu 12.04
2) Shotwell 0.11.93
3) Nokia 5800

I would like to help with more information regarding this, if necessary, so let me know if it is needed.

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: gvfs-backends 1.11.5-1ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.33-generic 3.2.12
Uname: Linux 3.2.0-20-generic x86_64
ApportVersion: 1.95-0ubuntu1
Architecture: amd64
CrashCounter: 1
Date: Thu Mar 29 18:21:55 2012
ExecutablePath: /usr/lib/gvfs/gvfsd-gphoto2
ProcCmdline: /usr/lib/gvfs/gvfsd-gphoto2 --spawner :1.5 /org/gtk/gvfs/exec_spaw/8
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
SegvReason: writing NULL VMA
Signal: 11
SourcePackage: gvfs
Title: gvfsd-gphoto2 crashed with SIGSEGV in pthread_mutex_destroy()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo vboxusers

Related branches

Aspersieman (aspersieman) wrote :
Changed in gvfs (Ubuntu):
importance: Undecided → Medium
summary: - gvfsd-gphoto2 crashed with SIGSEGV in pthread_mutex_destroy()
+ gvfsd-gphoto2 crashed with SIGSEGV in __pthread_mutex_destroy()
tags: removed: need-amd64-retrace
Launchpad Janitor (janitor) wrote :

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

Changed in gvfs (Ubuntu):
status: New → Confirmed
Changed in gvfs (Ubuntu):
importance: Medium → High
visibility: private → public
Changed in gvfs (Ubuntu Precise):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
papukaija (papukaija) on 2012-04-11
tags: added: i386
Martin Pitt (pitti) wrote :

This stack trace makes little sense. In do_mount(), we see that the gphoto2_backend is initialized:

       gphoto2_backend = 0x9930e0

A few lines before release_device (gphoto2_backend) it even dereferences gphoto2_backend->camera, and that did not give a segfault, so at that point gphoto2_backend was still valid. But at this call, the stack trace claims

#2 0x00000000004058c5 in release_device (gphoto2_backend=0x0) at gvfsbackendgphoto2.c:621

This cannot be true, before line 621 release_device() derefs gphoto2_backend dozens of times. So that 0x0 is wrong.

Martin Pitt (pitti) wrote :

I think that gphoto2_backend->lock is also not NULL, as g_mutex_clear() derefs it: g_mutex_impl_free (mutex->p); it seems it's gphoto2_backend->lock->p which is NULL then, i. e. the mutex was not initialized properly.

The only access to this aside from the _lock()/_unlock() calls is in do_mount() line 1715, i. e. it gets initialized _after_ release_device() is called (which tries to free it again).

Changed in gvfs (Ubuntu Precise):
status: Confirmed → In Progress
assignee: Canonical Desktop Team (canonical-desktop-team) → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

I sent a patch to the upstream bug.

Changed in gvfs (Ubuntu Precise):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.12.0-0ubuntu4

---------------
gvfs (1.12.0-0ubuntu4) precise; urgency=low

  * Add 07_gphoto2_mutex_init.patch: gphoto2: Initialize mutex early enough.
    (LP: #968186)
 -- Martin Pitt <email address hidden> Wed, 11 Apr 2012 12:18:11 +0200

Changed in gvfs (Ubuntu Precise):
status: Fix Committed → Fix Released
Changed in gvfs:
importance: Unknown → High
status: Unknown → In Progress
Changed in gvfs:
status: In Progress → Fix Released
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.