gvfs-gdu-volume segfault in libgdu.so.0.0.0

[ 156.247107] gvfs-gdu-volume[4331]: segfault at c ip 003bdfda sp bf81e800 error 4 in libgdu.so.0.0.0[3b5000+22000]
[ 737.169693] gvfs-gdu-volume[5220]: segfault at c ip 00357fda sp bf9b0270 error 4 in libgdu.so.0.0.0[34f000+22000]
[ 756.972067] gvfs-gdu-volume[5242]: segfault at c ip 0017afda sp bfc794d0 error 4 in libgdu.so.0.0.0[172000+22000]
[ 833.681471] gvfs-gdu-volume[5291]: segfault at c ip 009a8fda sp bfd2e9d0 error 4 in libgdu.so.0.0.0[9a0000+22000]

Linux xbox-laptop 2.6.30-5-generic #6-Ubuntu SMP Mon May 11 19:56:30 UTC 2009 i686 GNU/Linux

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, your crash report is either missing or challenging to deal with as a '.crash' file. Please follow these instructions to have apport report a new bug about your crash that can be dealt with by the automatic retracer.

 If you are running the Ubuntu Stable Release you might need to enable apport in /etc/default/apport and restart.

 If you are using Ubuntu with the Gnome desktop environment - launch nautilus and navigate to your /var/crash directory and double click on the crash report you wish to submit.

 If you are using Kubuntu or Xubuntu you can file the crash using /usr/share/apport/apport-qt --crash-file=/var/crash/_my_crash_report.crash in a terminal - where _my_crash_report.crash is the crash you would like to report.
 I'm closing this bug report since the process outlined above will automatically open a new bug report which can then dealt with more efficiently. Thanks in advance for your cooperation and understanding.

don't code the version in the title, is the bug specific to alpha 1 or still there in karmic? that just create confusion and extra work for triager

1) If you read my original report you'll see that apport didn't catch the crash. There is no crash file. I tried to attach with gdb but the process doesn't run continuously. I have however provided steps to reproduce which seem to work reliably (here at least.)

2) I haven't tested the bleeding edge - I thought the point of the alpha releases was to get a few more people testing than those that have time to continually follow the development release. If not, what _is_ the point of them? Or is there some other route for reporting alpha bugs that I don't know about - and isn't mentioned at www.ubuntu.com/testing ?

I have a fair bit of linux knowledge and have done development in the past but I'm increasingly regressing to just being a user, albeit a user with a fair bit of (possibly slightly out of date) background knowledge. I wonder if some thought should be put into drawing up a short list of different categories of users and clarifying what methods each category should use to interact with the developers -- if any?

> 1) If you read my original report you'll see that apport didn't catch the crash.

Did you enable apport as explained before? It's not running by default

> 2) I haven't tested the bleeding edge - I thought the point of the alpha releases was to get a few more people testing than those that have time to continually follow the development release. If not, what _is_ the point of them?

Not sure what is your issue there, just don't abuse the bug title to specify the version, that will quickly create confusion and the description already has the exact gvfs version used

> I wonder if some thought should be put into drawing up a short list of different categories of users and clarifying what methods each category should use to interact with the developers -- if any?

what do you mean exactly?

bug #376145 could be your issue but not easy to say without a debug stacktrace, steps are not always enough especially if the issue depends of the harware you are using

Just updated my VM to the current state of karmic, this is still happening. The nautilus windows no longer close themselves but the segfault is still logged by the kernel.

This is still gvfs-backends 1.3git20090512-0ubuntu1. libgdu0 is 0.3.0-0ubuntu2.

Attached is a manually updated Dependencies.txt (is there no way to get apport / ubuntu-bug to spit this out without filing a new report?)

"If you are running the _Ubuntu Stable Release_ you might need to enable apport in /etc/default/apport and restart."

Karmic is hardly the stable release, but you're right, having checked, apport is not enabled for some reason.

>> I wonder if some thought should be put into drawing up a short list of different categories of users and clarifying
>> what methods each category should use to interact with the developers -- if any?
> what do you mean exactly?

Bug reports and testing are solicited from end-users but do not always seem to be welcomed with opened arms! I understand that bug herding is a very time consuming job, but bug reporting also requires a certain investment of time. If there is an intended audience for, say, alpha releases, perhaps that should be mentioned somewhere so we don't waste each other's time. If I'm testing a particular alpha release, mentioning that in the bug title doesn't seem like an obvious breach of ettiquette ..

OK, it does look like a duplicate of bug #376145.

Note: I'm the original reporter of bug 376145 so apport did certainly trigger for me at least once. However, right now on karmic with all updates up to may 17th I consistently see 3 gvfs-gdu-volume crashes in my dmesg after every single reboot and none of these get detected by apport (could it be that they are supressed because I previously submitted that gvfs-gdu-volume? afaik apport does not work that way? on another karmic machine I have a kernel oops that happens during every boot and for that one apport certainly asks me to report it every single time). Besides the gvfs-gdu-volume bug itself, I also think there is something wrong with apport in karmic:

[ 75.536602] gvfs-gdu-volume[3997]: segfault at c ip 00118fda sp bf9a5c20 error 4 in libgdu.so.0.0.0[110000+22000]
[ 77.946651] gvfs-gdu-volume[4015]: segfault at c ip 00d65fda sp bf847880 error 4 in libgdu.so.0.0.0[d5d000+22000]
[ 83.860279] gvfs-gdu-volume[4037]: segfault at c ip 00afdfda sp bff10380 error 4 in libgdu.so.0.0.0[af5000+22000]

On Sun, May 17, 2009 at 11:59:00AM -0000, Martin Olsson wrote:

> However, right now on karmic with all updates up to may 17th I
> consistently see 3 gvfs-gdu-volume crashes in my dmesg after every
> single reboot and none of these get detected by apport (could it be
> that they are supressed because I previously submitted that
> gvfs-gdu-volume? afaik apport does not work that way?

There's a checkbox in the dialog that comes up that allows you to ignore
future crashes for that program, but even though I didn't tick it I see
the following in /var/log/apport.log:

apport (pid 3511) Sun May 17 13:29:43 2009: this executable already crashed 2 times, ignoring

(I got a slew of apport dialogs when I logged in and cancelled them
because I didn't want to deal with them at that point. Didn't apport
used to quietly display a notification icon when there were crash
reports that needed sending, or am I imagining it?)

I can confirm this too on Karmic.
Curiously HALd also refuses to start.

The error message telling gvfs-gdu-volume crashed comes very soon after logging in, together with an error message about bzr-notify crashing, as reported in bug #391158.

Running 'sudo hald --verbose=yes' gives no error messages, neither does running 'sudo /etc/init.d/hal start', even though its status is not running.

Running '/usr/lib/gvfs/gvfs-gdu-volume-monitor' doesn't give you the next emtpy line in the console, but doesn't output anything at all.

Both hal and gvfs-gdu-volume-monitor don't show up at all when you try to run them manually. The only remaining process with hal in it was gvfs-hal-volume(something?).

Uggh. Commented on the wrong bug. I actually wanted to comment on bug #376145.
My apologizes for the noise.