Red Hat Bugzilla – Bug 459662
OpenOffice.org "g_file_enumerate_children" crash on attempting to save, some data loss. Perhaps standby-related?
Last modified: 2008-08-20 18:16:15 EDT
I'm posting this for a friend who needs to get a bugzilla account. I'm sure he will soon
(hint, o friend..). He has ventured to put Linux onto his laptop. Fedora 9 from one of
the "buy the CDs over the net" UK vendors, no updates because net access not yet
sorted out, so it's whatever version of OO.o came with that.
He's put a lot of his old documents from old Windows and DOS machines on there
and has been editing new and old documents and saving them happily. At some
stage he tried to save something and OO.o crashed. The only thing he can think of
that was different was that the laptop had been on standby rather than hibernate
for the first time shortly before, and the battery had run down. He has tried to
reproduce - with little success, but he knows what he did the first time.
His account follows, complete with OO.o stack trace. I'll point him at bugzilla,
and in the meantime I'll catch any questions for him.
The computer is a SPIDER Model no 321. The Hard Disk is reported as being 72
GB. 9.4GB are in use, and 62.7 GB reported as free. It was originally supplied
with Windows XP, but having been bought solely to run Linux, that system was
installed (originally a fairly early version) in place of Windows. A newer
version of Linux was obtained on the advice of friends, and installed without
There were four open documents at the time the problem occurred:
one text document (Cast0004.doc) which had been recovered after the laptop had
been left on standby rather than
put to hibernate. No changes had been made to this document during the
session. (This document started life being edited in WordPerfect, was saved in
Microsoft Word format to be transferred to this computer, and had been
edited and saved in that format on a number of occasions without problem.
three spreadsheets (IHld3107ca.xls) which had been recovered after the laptop
had been left on standby rather than
put to hibernate. No changes had been made to this document during the session
ard-i8_2.xls which had been opened, but to which no changes had yet been made.
cyd-i820.xls on which a substantial amount of work had been done, and which
work had been saved. I was in the process of saving this document under a new
name (using Ctrl +Shift+S,rather than the drop-down menu) when the problem
arose. The final sheet had been copied and renamed.
After starting to create this Bug Report, I closed all open files, leaving
only OpenOffice open All four of the files named above were supposedly open, but
Open Office did not respond. I forced the system to close all the files - the
system did eventually respond, but showed no information from the files on the
screen. I then shut down the system using the GUI menu
System > Shut down > Restart
Having restarted the system I then started Open Office from the GUI menu
Applications > Office
which brought up a screen which allowed me to choose whether to recover all
four documents. This I did, letting the software control the process. One
document (ard-i8_2 apparently has links to other spreadsheets, but I did not
select the opportunity to refresh these (I do not know where they are - if I
could identify them I would delete them!)
Each of the recovered documents has been examined.
Cast004.doc appears unchanged. It has been modified slightly, saved under the
same name and closed.
IHld3107ca.xls appears unchanged. It has been modified slightly, saved under
the same name and closed.
ard-i8_2.xls appears unchanged. It has been modified slightly, saved under the
same name but kept open.
cyd-i820.xls appears to have retained the substantial modifications made, but
no modifications made since the attempt to copy and to place the copy at the
end, and subsequently rename the last sheet, seem to have been
retained. I have therefore repeated, so far as I could, the operations
performed immediately before the crash.
1) Copy the final sheet and place the copy at the end
2) Rename the copy
3) Save the file under a new name (cyd-i830) using Ctrl+Shift+S. Unfortunately
this did not provoke a second crash!!
ard-i8_2.xls has subsequently been edited, saved, and saved again under a new
name (ard-i8_3.xls). No further problems so far!!
A note on the naming conventions I use for files, and within files. Until a
couple of years ago I did much of my work on a 386 running MS-DOS with DesqView
providing a windowing system. Most of the work I did on that computer was
word-processing; I used WordPerfect 5.1 and a specialised program, EW+. I have
since moved to WordPerfect 12 for Windows, which I use on computers running
Windows 98, and Windows XP. In order to ensure an ASCII sort under MS-DOS where
files need to be stored in date order, I adopted a system where the year was
represented by two digits - decade and year. From 1999 on I replaced the second
numeral with a letter - so that A=2000, B=2001 etc. The series ard- and cyd-
both began after 2000, so only one digit has been used to indicate the year:
thus ard-i and cyd-i must both relate to 2008. The month is indicated by one
digit, so Jan - Sep are 1-9 and Oct, Nov and Dec are A, B & C. This convention
can and has been extended to allow for dates in the
Old Style to be represented unambiguously so that D, E & F represent January,
February and March.
The information below is pasted in from the crash report immediately after
Open Office crashed.
Passwords are used only for the root and the sole user. There are currently no
data files on the computer that are password protected.
My normal practice is to set the computer to Hibernate between work sessions.
However on the last occasion I was using it prior to the crash, I had SUSPENDed
operation, intending to return to my work; in the event I did not do so, and
when I restarted the computer, the battery had run down, and the two documents
open (Cast0004.doc & IHld3107ca.xls) were recovered when I restarted OpenOffice.
I have had problems restarting the computer on one previous occasion when I
tried to SUSPEND operations instead of setting the computer to HIBERNATE.
(I) x.org loaded video driver of...
(II) Loading /usr/lib/xorg/modules/drivers//sis_drv.so
(--) Depth 24 pixmap format is 32 bpp
(III) Desktop is: GNOME
(IV) openoffice.org-kde version is: package openoffice.org-kde is not
(V) libgcj version is: libgcj-4.3.0-8-i386
(IV) kernel is: Linux 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008
i686 i686 i386
(VII) OpenOffice.org core rpm version is:
(VIII) accessibility is: false
(VIV) fedora release is: Fedora release 9 (Sulphur)
(VV) LANG is: en_US.utf8
...start free space details ...
Filesystem 1K-blocks Used Available Use% Mounted on
37704364 4941456 30847620 14% /
37704364 4941456 30847620 14% /
...end free space details ...
...start sestatus details ...
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 22
Policy from config file: targeted
...end sestatus details ...
...start stackreport details ...
0x47373e8: 0x1c4c7c: /usr/lib/openoffice.org/program/libuno_sal.so.3 + 0x253e8
0x4737d23: 0x1c4c7c: /usr/lib/openoffice.org/program/libuno_sal.so.3 + 0x25d23
0x110400: 0x0: + 0x400 (__kernel_sigreturn + 0x0)
0x110416: 0x0: + 0x416 (__kernel_vsyscall + 0x2)
0x78e660: 0x164d7c: /lib/libc.so.6 + 0x2a660 (gsignal + 0x50)
0x790028: 0x164d7c: /lib/libc.so.6 + 0x2c028 (abort + 0x188)
0x99104a: 0xe0108: /lib/libglib-2.0.so.0 + 0x4104a (g_logv + 0x5ca)
0x991086: 0xe0108: /lib/libglib-2.0.so.0 + 0x41086 (g_log + 0x26)
0xd03d2a: 0x3f544: /lib/libgobject-2.0.so.0 + 0x28d2a (g_type_class_ref +
0xcea8c0: 0x3f544: /lib/libgobject-2.0.so.0 + 0xf8c0 (g_object_newv + 0xb60)
0xceaca7: 0x3f544: /lib/libgobject-2.0.so.0 + 0xfca7 (g_object_new_valist +
0xceae1e: 0x3f544: /lib/libgobject-2.0.so.0 + 0xfe1e (g_object_new + 0x6e)
0x2b9b2f0: 0x6bf0c: /lib/libgio-2.0.so.0 + 0x442f0
0x2b99d4c: 0x6bf0c: /lib/libgio-2.0.so.0 + 0x42d4c
0x2b73e56: 0x6bf0c: /lib/libgio-2.0.so.0 + 0x1ce56 (g_file_enumerate_children
0x2b75054: 0x6bf0c: /lib/libgio-2.0.so.0 + 0x1e054
0x2b89679: 0x6bf0c: /lib/libgio-2.0.so.0 + 0x32679
0x2b83054: 0x6bf0c: /lib/libgio-2.0.so.0 + 0x2c054
0x9b2b06: 0xe0108: /lib/libglib-2.0.so.0 + 0x62b06
0x9b146f: 0xe0108: /lib/libglib-2.0.so.0 + 0x6146f
0x90732f: 0x14ed4: /lib/libpthread.so.0 + 0x632f
0x84227e: 0x164d7c: /lib/libc.so.6 + 0xde27e (clone + 0x5e)
...end stackreport details ...
...start sample ldd details ...
linux-gate.so.1 => (0x00110000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00162000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00562000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x005f8000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00615000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00632000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x0063c000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x0067f000)
libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x006ee000)
libdl.so.2 => /lib/libdl.so.2 (0x006f2000)
libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x006f7000)
librt.so.1 => /lib/librt.so.1 (0x006fc000)
libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00706000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00762000)
libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x007a3000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x007e3000)
libvcl680li.so => /usr/lib/openoffice.org/program/libvcl680li.so (0x00943000)
libpsp680li.so => /usr/lib/openoffice.org/program/libpsp680li.so (0x00cc9000)
libsot680li.so => /usr/lib/openoffice.org/program/libsot680li.so (0x00daa000)
libutl680li.so => /usr/lib/openoffice.org/program/libutl680li.so (0x00e08000)
libtl680li.so => /usr/lib/openoffice.org/program/libtl680li.so (0x00e8e000)
libcomphelp4gcc3.so => /usr/lib/openoffice.org/program/libcomphelp4gcc3.so
libucbhelper4gcc3.so => /usr/lib/openoffice.org/program/libucbhelper4gcc3.so
libuno_cppu.so.3 => /usr/lib/openoffice.org/program/libuno_cppu.so.3
libvos3gcc3.so => /usr/lib/openoffice.org/program/libvos3gcc3.so (0xb7d46000)
libuno_sal.so.3 => /usr/lib/openoffice.org/program/libuno_sal.so.3
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7a79000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00724000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00f5f000)
libstlport_gcc.so => /usr/lib/openoffice.org/program/libstlport_gcc.so
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb78bc000)
libm.so.6 => /lib/libm.so.6 (0xb7892000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00734000)
libc.so.6 => /lib/libc.so.6 (0xb7729000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00f78000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00f7b000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7702000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb76d2000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb76c9000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00f80000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb76c0000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb76b9000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb76ae000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7684000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb75f5000)
libz.so.1 => /lib/libz.so.1 (0xb75e1000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb75b4000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb7597000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb757d000)
libcap.so.2 => /lib/libcap.so.2 (0xb7579000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb7570000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb7556000)
libbasegfx680li.so => /usr/lib/openoffice.org/program/libbasegfx680li.so
libicuuc.so.38 => /usr/lib/libicuuc.so.38 (0xb73c5000)
libicule.so.38 => /usr/lib/libicule.so.38 (0xb738e000)
libjvmaccessgcc3.so.3 => /usr/lib/openoffice.org/program/libjvmaccessgcc3.so.3
libjvmfwk.so.3 => /usr/lib/openoffice.org/program/libjvmfwk.so.3 (0xb736b000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7335000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00742000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7318000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7315000)
libexpat.so.1 => /lib/libexpat.so.1 (0xb72ee000)
libicudata.so.38 => /usr/lib/libicudata.so.38 (0xb6817000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb66c7000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb66c1000)
...end sample ldd details ...
This is a crash in gio, so the most interesting thing to find out would be what sort of gio mounts might there have been, i.e. connect to server sort of things, especially as to *where* the files were located, were they just on the local disk ?
same stack as #446619
*** This bug has been marked as a duplicate of bug 446619 ***