Summary: | >=gnome-base/gvfs-1.6.7: several gnome apps (nautilus, gedit, evince) crashes to do unaligned memory access | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | chghs |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | Keywords: | PATCH |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | Sparc | ||
OS: | Linux | ||
URL: | https://bugzilla.gnome.org/show_bug.cgi?id=658794 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 371525 | ||
Attachments: |
gdb output when starting evince to open a document
gdb output when starting gedit to open a document output of 'G_DBUS_DEBUG=all evince ./pdf_test.pdf > output_evince.txt' Output of gvfs-mount -l Xorg-Log (old) after calling 'nautilus .' which crahes Xorg-Log after calling 'nautilus .' which crahes (no modifications in log file) |
Description
chghs
2011-08-24 20:07:20 UTC
Created attachment 284527 [details]
gdb output when starting evince to open a document
This output was generated with
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-oo8oQvSOpI,guid=c2d97c06cda8f31521caf89e00000144
Created attachment 284529 [details]
gdb output when starting gedit to open a document
This output was generated with
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-oo8oQvSOpI,guid=c2d97c06cda8f31521caf89e00000144
If this variable is cleared, no error occurs.
Further output of dbus-monitor can be provided if of interest. See also discussion at http://forums.gentoo.org/viewtopic-t-890582.html?sid=33394ff5b4473a9e29691352e5497cc3 Please attach the complete output of the following command: G_DBUS_DEBUG=all evince (In reply to comment #4) > Please attach the complete output of the following command: > G_DBUS_DEBUG=all evince or better yet, tell it to open some existing pdf document (change the path accordingly): G_DBUS_DEBUG=all evince ~/some_random_document.pdf Created attachment 284533 [details]
output of 'G_DBUS_DEBUG=all evince ./pdf_test.pdf > output_evince.txt'
lariano@elnath ~ $ env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-oo8oQvSOpI,guid=c2d97c06cda8f31521caf89e00000144
lariano@elnath ~ $ ls -l pdf_test.pdf
-rw-r--r-- 1 lariano lariano 95502 Aug 17 11:23 pdf_test.pdf
lariano@elnath ~ $ G_DBUS_DEBUG=all evince ./pdf_test.pdf > output_evince.txt
Were there any error messages in the terminal before the crash? (You redirected stdout to output_evince.txt, but stderr would still have been printed in the terminal.) The call of evince and gedit produces no error messages in the terminal nor in .xsession-errors nor in the system log file which for me is under /var/log/everything/current. Since these tools are compiled with debug options, at the end of the crash the Bug Reporting Tool opens :-) Calling 'nautilus .' in my home directory produces the following error in the system log file: Aug 25 20:08:54 [dbus] [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.21" (uid=1000 pid=2157 comm="nautilus ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.1" (uid=0 pid=1290 comm="/usr/sbin/console-kit-daemon --no-daemon ") and an entry in .xsession-errors: nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Initializing nautilus-gdu extension ** Message: Initializing gksu extension... That's all I have found. Very interesting... It appears that there isn't anything wrong with the dbus or gdbus part of the equation. Next guess: maybe the bug is in gvfs. What version of gvfs do you have emerged, and with what USE flags? Please give the output of gvfs-mount -l Also, please try GIO_USE_VFS="local" evince ./pdf_test.pdf Does that still crash? If it does, and the backtrace is different, please attach it. (In reply to comment #8) [...] > and an entry in .xsession-errors: > > nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. > Initializing nautilus-gdu extension > ** Message: Initializing gksu extension... > > That's all I have found. Please attach /var/log/Xorg.0.log and /var/log/Xorg.0.log.old just after getting that message Created attachment 284735 [details]
Output of gvfs-mount -l
I noticed that the boot device is not listed in the output of 'gvfs-mount -l'. On ly cdrom and a secondary hard disk is found.
# Setting GIO_USE_VFS="local" for the call of evince works!!! No crash!!! lariano@elnath ~ $ env | grep DBUS DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-qhJMTfxFAF,guid=dc8aa7571df5a7898074fbab00000031 lariano@elnath ~ $ ls -l ./pdf_test.pdf -rw-r--r-- 1 lariano lariano 95502 Aug 17 11:23 ./pdf_test.pdf lariano@elnath ~ $ file ./pdf_test.pdf ./pdf_test.pdf: PDF document, version 1.5 lariano@elnath ~ $ GIO_USE_VFS="local" evince ./pdf_test.pdf lariano@elnath ~ $ # NO CRASH :)) lariano@elnath ~ $ # The command works also for gedit GIO_USE_VFS="local" gedit gedit_test.txt # NO CRASH !!! Created attachment 284741 [details]
Xorg-Log (old) after calling 'nautilus .' which crahes
lariano@elnath ~ $ date
Fri Aug 26 21:23:41 CEST 2011
lariano@elnath ~ $ tail -f .xsession-errors
...
nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Initializing nautilus-gdu extension
** Message: Initializing gksu extension...
nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Initializing nautilus-gdu extension
** Message: Initializing gksu extension...
elnath log # ls -l Xorg*
-rw-r--r-- 1 root root 71096 Aug 26 20:52 Xorg.0.log
-rw-r--r-- 1 root root 77917 Aug 26 20:47 Xorg.0.log.old
elnath log #
# No modification in Xorg.0.log on crash of nautilus
Created attachment 284743 [details]
Xorg-Log after calling 'nautilus .' which crahes (no modifications in log file)
The Xorg.0 log file. The file was not modified by crash.
(In reply to comment #9) > Very interesting... > > It appears that there isn't anything wrong with the dbus or gdbus part of the > equation. Next guess: maybe the bug is in gvfs. > > What version of gvfs do you have emerged, and with what USE flags? > > Please give the output of gvfs-mount -l Then, Tetromino was right and this looks to be a gvfs problem, can you provide your gvfs version and USE flags for it? Forgot it, both are present in attached file :S After much investigation I have found the following conclusion:
My sparc system is not able to read a guint64 value if the addressed memory section is not 64-bit-aligned. This is the case when line 1306 of gvfs-1.6.7/metadata/metatree.c the value for guint64 mtime should be read:
mtime = GUINT64_FROM_BE (entry->mtime);
The memory section for reading mtime is created in line 1172:
data = mmap (NULL, statbuf.st_size, mmap_prot, MAP_SHARED, fd, 0);
This section starts with a 20-byte header (MetaJournalHeader) followed by 2x4 byte section for
guint32 entry_size;
guint32 crc32;
Hence the value of guint64 mtime starts for the first entry of the journal at the offset 20 + 4 + 4 = 28 which is clearly not 8-byte-aligned. Testing a read operation at offset 0 in contrast (which is on my system always 8-byte-aligned) is successful. I have found a short patch which consists in reading two times a guint32 value and combining the results for a guint64 value:
lariano@elnath ~/work/anjuta/gvfs-1.6.7/metadata $ diff metatree.c.orig metatree.c
1306c1306,1312
< mtime = GUINT64_FROM_BE (entry->mtime);
---
> guint32* big_part = (guint32*)((char*) entry + 8);
> guint64 big_part_64 = *big_part;
> big_part_64 <<= 32;
> guint32* little_part = (guint32*)((char*) entry + 12);
> guint64 big_little = (big_part_64 | ((guint64)(*little_part)));
> mtime = GUINT64_FROM_BE (big_little);
>
With this patch the problem for nautilus, gedit, evince and other desktop applications has gone. Only the clock-applet seems to have another problem :)
Thanks a lot for your investigation. Looking at updated .c file from gvfs trunk, looks like this problem could still be unfixed by upstream: http://git.gnome.org/browse/gvfs/tree/metadata/metatree.c Could you please report this problem and you patch to upstream to let them know the problem and commit if ok? -> bugzilla.gnome.org Thanks a lot Since upstream has been unresponsive to say the least, we really should add that patch to the ebuild if it fixes the problem. What say you team ? (In reply to comment #22) > Since upstream has been unresponsive to say the least, we really should add > that patch to the ebuild if it fixes the problem. What say you team ? I would much prefer a patch that ensures gvfs's structs are always written to aligned addresses in a buffer. (In reply to Alexandre Rostovtsev from comment #23) > (In reply to comment #22) > > Since upstream has been unresponsive to say the least, we really should add > > that patch to the ebuild if it fixes the problem. What say you team ? > > I would much prefer a patch that ensures gvfs's structs are always written > to aligned addresses in a buffer. Do we keep waiting or use current patch? (I don't have enough knowledge to modify it following tetromino's suggestions, and this is now two years old problem :/ ) Will handle this directly on upstream bug as looks like they don't like this patch so much :( |