gvfsd-gphoto2 crashed with SIGSEGV in strlen()

Same error today, now on Ubuntu Studio Beta. Same action, plugged in a Zen Vision and the system mounted it as if a camera. This blocks out the functionality of Rhythmbox, Gnomad, etc, until I tell it to eject, at which point the crash popped up. After telling it to eject, but leaving plugged in, the player is now available to music programs, and works normally.
S*

Again tonite, same error doing the same thing. - Seems the Zen is interpreted as a camera somehow...
S*

StacktraceTop:strlen () at ../sysdeps/i386/i486/strlen.S:69
split_filename_with_ignore_prefix (
do_enumerate (backend=0x8ab6800, job=0x8b45330,
run (job=0x8b45330) at gvfsjobenumerate.c:260
g_vfs_job_run (job=0x8b45330) at gvfsjob.c:198

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=577417

Do you get the issue every time? Do you think you could try to obtain a valgrind log following the instructions at https://wiki.ubuntu.com/Valgrind and attach the file to the bug report

Sebastian - got valgrind installed, but couldn't figure out how to attach it to whichever program to make it log... The wiki page is pretty vague. I replaced <program> with gvfsd-ghoto2 and it says 'command not found'. Not sure what I need to do here to fire up valgrind.

This does happen every time. Again, it seems to be a mount error. It's like the Zen is trying to mount twice.
Anyways, fill me in on syntax, etc to get logs back to you.
S*

the correct binary name is /usr/lib/gvfs/gvfsd-photo2, an another way is to mv the binary and have a wrapper using the normal name copy "valgrind binarycopy"

 if you could dumb down your explanation a bit more.... what do i need to enter into the <program><arguements> fields to enable valgrind. I know what mv does, i've heard of wrappers, etc - but couldn't make one at this point. I have some good Linux experience, but am in no way fluent quite yet.

S*

> Date: Thu, 2 Apr 2009 07:39:34 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 349555] Re: gvfsd-gphoto2 crashed with SIGSEGV in strlen()
>
> the correct binary name is /usr/lib/gvfs/gvfsd-photo2, an another way is
> to mv the binary and have a wrapper using the normal name copy "valgrind
> binarycopy"
>
> --
> gvfsd-gphoto2 crashed with SIGSEGV in strlen()
> https://bugs.launchpad.net/bugs/349555
> You received this bug notification because you are a direct subscriber
> of the bug.

cd /usr/lib/gvfs
sudo mv gvfsd-photo2 gvfsd-photo2.binary
sudo gedit gvfsd-photo2

write
"#!/bin/sh
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --log-file=/tmp/valgrind.log gvfsd-photo2.binary $@"

sudo chmod 775 gvfsd-photo2

restart your session
get the crash
add /tmp/valgrind.log there

So, came home and got all set up. Plugged in the Zen, and (of course), worked as always and as expected, did not auto mount and cause the crash... So, at this time I suppose the gvfsd-gphoto2 crash problem is solved... However, the system isn't quite right concerning the Zen. It works with Gnomad fine now. Rhythmbox mounts it if you have MTP devices enabled, and I'm able to browse and play music fine. When I exit Rhythmbox, it never unmounts, the played stays in a docked mode. If I use the eject function while in Rhythmbox, it ejects fine. If I exit rhythmbox it stays docked, but at that point it won't let me eject from the filesystem. If I go to 'Places' and choose the Zen, it does not let me eject, it just stays docked until I open Rhythmbox and use the eject there, which works fine.

Biggest problem seems to be in (maybe) libmtp8, which is not treating the Zen as hotplug-able, which is of course NOT the case with iPod. The Zen usually allows hot plug, programs shouldn't care so much if I rip the plug out, unless there is a transfer going on or something like that. iPod never allows this without using eject.
Just a thought.

Can't remember exactly what caused it, but also got this today:

DBus error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)

Anything else I can do to help, please contact me.
S*

> Date: Thu, 2 Apr 2009 13:57:13 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 349555] Re: gvfsd-gphoto2 crashed with SIGSEGV in strlen()
>
> cd /usr/lib/gvfs
> sudo mv gvfsd-photo2 gvfsd-photo2.binary
> sudo gedit gvfsd-photo2
>
> write
> "#!/bin/sh
> G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --log-file=/tmp/valgrind.log gvfsd-photo2.binary $@"
>
> sudo chmod 775 gvfsd-photo2
>
> restart your session
> get the crash
> add /tmp/valgrind.log there
>
> --
> gvfsd-gphoto2 crashed with SIGSEGV in strlen()
> https://bugs.launchpad.net/bugs/349555
> You received this bug notification because you are a direct subscriber
> of the bug.

does it work correctly now?

This particular problem seems to be gone since the last update. Have not been able to replicate it the last two days.

Gnomad works like it should, mostly - plug in the player, open gnomad, it mounts and lets me add tracks, etc... However, if I try to edit a track, it completely locks the program, to the point that I have to kill it to shut the program down. If I don't attempt that, it seems to work ok, although that function is kind of a big part of music management.

Rhythmbox works well, with MTP enabled, and allows playback, etc from the Zen. The only weird thing is that it does not eject/unmount when finished. If I exit without using the eject in Rhythmbox, I get a pop-up error:

'Unable to mount Creative Technology, Ltd Creative Zen Vision:M
DBus error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)'

If I then go and re-open Rhythmbox, I can use it again, and then eject within the program and everything is back to normal. Probably should have rhythmbox unmount on close for MTP.

Should probably forward that info along to rhythmbox/mtp folks.
Also not sure about the problem with Gnomad, if it has to do with libmtp or what

S*

> Date: Fri, 3 Apr 2009 10:55:10 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 349555] Re: gvfsd-gphoto2 crashed with SIGSEGV in strlen()
>
> does it work correctly now?
>
> --
> gvfsd-gphoto2 crashed with SIGSEGV in strlen()
> https://bugs.launchpad.net/bugs/349555
> You received this bug notification because you are a direct subscriber
> of the bug.

closing the gvfs bug since the crash seems fixed now

Back again - happened today the same thing. When Zen is attached it 'mounts' for a second or two to id, then should not stay mounted. It does release, but then immediately mounts a second time and causes the error. At that point I have to go into 'Places', etc and unmount from the side of the window (by hitting the eject symbol). Otherwise works ok it seems. I've heard reference to this being maybe related to libnjb, or possibly libmtp8. Sorry to not have more.
S*

reopening the bug, new bug is bug 357954

On latest comment from the upstream developer it says that this maybe is a memory corruption, may you please try to obtain a valgrind log following the instructions at https://wiki.ubuntu.com/Valgrind and attach the file to the bug report. This will greatly help us in tracking down your problem. Thanks in advance.

Here is valgrind log. This is happens when Zen is plugged in for the first time. If I leave machine running it doesn't seem to happen until next startup. However, the issue with the Zen 'double mounting' happens all the time. Something is definitely not right in how the system is identifying or mounting the Zen...

there is no error in this log

Regardless, the error listed in the beginning comes up without fail. I've heard complaints of this maybe being a problem with a missing udev rule, or possibly a binary package. I am willing to try to help track it another way. My question is maybe why is gphoto trying to run if it's not a photo device..?

I tried about a week ago same setup, on Debian 5.0. Everything worked as normal. Hardy worked just fine. I currently compiled latest libmtp, gnomad2 and Jaunty still mounts/docks incorrectly.

AT this point I feel that it has alot more to do with how it is being handled by the USBbus, not so much with gphoto, etc...

The biggest hint I have is the double mounting aspect. When plugged in, in the past (and on Debian), the Zen will 'mount' briefly, then disengage, making it available to mount through gnomad, rhythmbox, etc... On Jaunty since early Alpha stages, when plugged in it does the same action, but then immediately mounts a second time (I can watch it happen on the Zen screen), and stays in a 'docked' state to the system. It does not work with Gnomad or Rhythmbox at this point. If I pick it from the desktop or from places, etc... and choose to eject, it frees up and then is available to use normally.
This is the most obvious thing I see. Something changed in Jaunty as to how it is handled by USB, or by the system in general.

Again, I am willing to help by tracking whatever else it may be. The above valgrind log may not show any error, but it was on and logging and I got the same Gphoto error when plugged in that time. Tell me what other info you might need.
S*

how did you get the log? could you install the debug packages for gtk glib gvfs?

how did you get the log? could you install the debug packages for gtk glib gvfs? you might want to rename gvfsd-gphoto2 to gvfsd-gphoto2.binary and have a gvfsd-gphoto2 wrapper calling the binary under valgrind

I already explained the valgrind trick before, you might want to make sure that there is no running backend or that you don't restart one which would overwrite the log then or add some logic to name logs differently

I'm not sure what it is , but seems like when whenever you ask for more logging, etc the problem has vanished.....

Got home tonite and got all set up, plugged in and (of course), everything is as it's been in previous releases for the most part. No error came up _BUT - more importantly- the 'double mount' issue I brought up (above) seems to have been taken care of somewhere else. Everything is working as smooth as it did previous to Jaunty. Once again, seemed to be a USB or udev or somethin? problem.

I would like to leave this open for a day, I will give a few more trys to see if behavior changes or is actually fixed. I may try to reinstall clean with full updates just to see.... Fingers crossed...

S*

So - as of 4-13 updates, the problem seems to have gone away. I could not get the gvfs error to come up again.

I completely reinstalled the system with the release candidate, then got all updates and gnomad. Tried it again and still no error as far as gvfs is concerned.

However, the system was changed again, in that now it tries to mount the Zen every time, which is NOT how it should operate. If I let the system mount it and keep it mounted, then Gnomad, Rhythmbox, etc. do NOT work. I have to tell the system to unmount, and then related programs work as they are supposed to. Not sure where that bug goes from here, if it should reopen to system/usb programmers, or.... All I know is that it makes it sort of a pain to use, and it was definitely not this way prior to Jaunty development.

S*

Looking at the 'mounted' Zen. It shows it's properties as a gphoto2 filesystem. Once again, the issue seems to be that gphoto2 is mounting the Zen, which it should not be doing. It's not a camera or camera device. It can handle pictures, but only for viewing, and is easily loaded through Gnomad2.

I'm back to the 'double mount', where the Zen is mounted by the filesystem, and just as it releases, is remounted by gphoto2. It's then locked (docked) to the system through gphoto, and becomes unavailable for the programs that work with it - Gnomad2, and Rhythmbox. Until I manually(through desktop) go in and unmount, the Zen can't work with the programs that it's supposed to. Once unmounted it seems to work as expected, I haven't noticed any other problems other than this mount/gphoto2 issue.

So the gphoto error is gone, but gphoto should not be grabbing hold of the Zen player.

S*

closing the bug since the crash doesn't happen now, there is an another bug about mtp device being locked by gvfs see bug #348287