gvfsd-metadata crashed with SIGSEGV

[Jose Gómez]

Testing screen-reader installation for Natty Narwhal Beta2. image is Ubuntu-desktop-i386.iso, dated 2011-04-13.

1. start system with the cd in drive
2. hit any key after bios checks to get the cd menu
3. hit F5
4. down-arrow three times to screen-reader
5. enter two times
when desktop stops, orca starts and this error will appear shortly.

After the live desktop started, I used Alt+F1, right-arrow, right-arrow, down-arrow to select install 11.04. This error appears on screen.

ProblemType: Crash
DistroRelease: Ubuntu 11.04
Package: gvfs 1.7.3-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.38-7.38-generic 2.6.38
Uname: Linux 2.6.38-7-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
CrashCounter: 1
Date: Tue Mar 29 10:20:24 2011
ExecutablePath: /usr/lib/gvfs/gvfsd-metadata
ProcCmdline: /usr/lib/gvfs/gvfsd-metadata
ProcEnviron:
 SHELL=/bin/bash
 LANGUAGE=en_US:en
 LANG=en_US.utf8
SegvAnalysis:
 Segfault happened at: 0x804c92d: mov 0x8(%edx),%edx
 PC (0x0804c92d) ok
 source "0x8(%edx)" (0x00000008) not located in a known VMA region (needed readable region)!
 destination "%edx" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: gvfs
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 ?? ()
 ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
Title: gvfsd-metadata crashed with SIGSEGV
UpgradeStatus: Upgraded to natty on 2011-03-04 (24 days ago)
UserGroups: adm admin audio cdrom dialout lp lpadmin netdev plugdev sambashare vboxusers

[Apport retracing service (apport)]

StacktraceTop:
 verify_metadata_block (tree=0x8cda1c0, dirent=0x0, builder_file=0x8cda270) at metatree.c:222
 copy_tree_to_builder (tree=0x8cda1c0, dirent=0x0, builder_file=0x8cda270) at metatree.c:2193
 meta_tree_flush_locked (tree=0x8cda1c0) at metatree.c:2354
 meta_tree_flush (tree=0x8cda1c0) at metatree.c:2375
 writeout_timeout (data=0x8cda250) at meta-daemon.c:61

[Jean-Baptiste Lallement (jibel)]

I can confirm this crash with the steps in bug 760107.
The crash dialog doesn't appear instantly and I had to wait a bit.

[Kate Stewart (kate.stewart)]

Upping the prioirty of this so we can get it figured out before the new features hit.

[Tiago M. C. (tiagocasal)]

Just using the computer; the process crashed in the background; livecd amd64.

[Martin Pitt (pitti)]

This crash is around for a fair while, and I don't think it's important enough to warrant being release critical. I linked it with the upstream bug and commented there, I'll follow up here if the patch attached there is considered correct.

[Pi Delport (pi-delport)]

This crash happened randomly in the background: i'm not sure what may have triggered it.

[wombat (jewett-aij)]

Not to dismiss the bug reports, but could the large number of these kinds of errors be caused by bad recording media (instead of a bug in ubuntu)? It seems like people posting here with this problem are booting from a live-cd image.

Though I doubt this is relevant, I run into these kinds of problems when booting from USB flash memory stick (a live-cd 11.10 amd64 w/ persistence). I'm guessing my USB memory stick has some bad blocks. (More details posted on bug 794757.) That's why I posted here.
No need to reply.

[wombat (jewett-aij)]

oops. nevermind. I just read the bug description more carefully.

[Mike Mestnik (cheako)]

I'd just like to update the record to include the trouble shooting steps for defective media. However after attempting to do so I realized I was no expert. Trying again seams best. Once an issue is reported by multiple media using multiple devices, it most likely is not defective media. Multiple different media with defects would likely express an array of different problems, save for failing a media verification step, not the same problem over and over again.

However a problem can be specific to a certain configuration, so determining the details of the configuration is a necessary troubleshooting step. Furthermore just because a configuration works 100 times, does not mean that it will not fail 10,000,000 times and the reverse is also true.

[Mike Mestnik (cheako)]

"badblocks -n" comes to mind. If the bootable USB drive passes this test, then it's 100% good.

[Mike Mestnik (cheako)]

I should learn to keep my mouth shut. "badblocks -n" is likely to cause USB flash defects, however it would indicate that the drive WAS 110% good.