Bug 459662 - OpenOffice.org "g_file_enumerate_children" crash on attempting to save, some data loss. Perhaps standby-related?
Summary: OpenOffice.org "g_file_enumerate_children" crash on attempting to save, some ...
Keywords:
Status: CLOSED DUPLICATE of bug 446619
Alias: None
Product: Fedora
Classification: Fedora
Component: glib2
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-08-20 21:49 UTC by Telsa Gwynne
Modified: 2008-08-20 22:16 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-20 22:16:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Telsa Gwynne 2008-08-20 21:49:59 UTC
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. 

------8<-----------

  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
problems.
  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.
  These were;
  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
installed
  (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:
openoffice.org-core-2.4.0-12.8.fc9-i386
  (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
  /dev/mapper/VolGroup00-LogVol00
  37704364 4941456 30847620 14% /
  /dev/mapper/VolGroup00-LogVol00
  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 +
0x56a)
  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 +
0x2b7)
  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
+ 0xc6)
  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)
  libvclplug_gen680li.so =>
/usr/lib/openoffice.org/program/libvclplug_gen680li.so (0x008c4000)
  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
(0xb7e6b000)
  libucbhelper4gcc3.so => /usr/lib/openoffice.org/program/libucbhelper4gcc3.so
(0xb7e00000)
  libuno_cppuhelpergcc3.so.3 =>
/usr/lib/openoffice.org/program/libuno_cppuhelpergcc3.so.3 (0xb7d6b000)
  libuno_cppu.so.3 => /usr/lib/openoffice.org/program/libuno_cppu.so.3
(0x00f31000)
  libvos3gcc3.so => /usr/lib/openoffice.org/program/libvos3gcc3.so (0xb7d46000)
  libuno_sal.so.3 => /usr/lib/openoffice.org/program/libuno_sal.so.3
(0xb7b7a000)
  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
(0xb79ae000)
  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)
  /lib/ld-linux.so.2 (0x00744000)
  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)
  libi18nisolang1gcc3.so =>
/usr/lib/openoffice.org/program/libi18nisolang1gcc3.so (0xb754f000)
  libbasegfx680li.so => /usr/lib/openoffice.org/program/libbasegfx680li.so
(0xb74f9000)
  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
(0xb7387000)
  libjvmfwk.so.3 => /usr/lib/openoffice.org/program/libjvmfwk.so.3 (0xb736b000)
  libuno_salhelpergcc3.so.3 =>
/usr/lib/openoffice.org/program/libuno_salhelpergcc3.so.3 (0xb7367000)
  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 ...

Comment 1 Caolan McNamara 2008-08-20 22:06:59 UTC
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 ?

Comment 2 Caolan McNamara 2008-08-20 22:16:15 UTC
same stack as #446619

*** This bug has been marked as a duplicate of bug 446619 ***


Note You need to log in before you can comment on or make changes to this bug.