Apache OpenOffice (AOO) Bugzilla – Issue 5108
Crash when saving to cfs
Last modified: 2003-05-15 09:55:24 UTC
OpenOffice wordprocessor crashes when saving a file to a cfs directory. reproducable, no error messages. if you open a document you moved into a cfs directory, and try to save it, even the old file is gone. Debian potato, Kernel 2.2.19, i686, KDE 2.1.2, OpenOffice 1.0
this relates to sal doesn't it?
reassigning to owner of selected component
OldFiSH, could you please provide some more info? Stands CFS for Coda file system or for Cryptographic file system?
Cryptographic file system (default on debian potato). Same behavior with self-compiled cfs 1.3.3 on SuSE 7.1.
OldFiSH, could you please provide some stack traces and can you please provide a link where to get cfs?
you can find cfs here (among other places): http://packages.debian.org/stable/non-us/cfs.html there is a debian package and also a source tarball on the above site. for the stack trace: using the command 'strace -o oo.trace.txt swriter', i got a pretty big file ( nearly 2 megs for app start, opening file, trying to save; you can get it from http://www.specker.li/oo.trace.txt ); i hope that's what you wanted... below are the last lines (don't know if that will do any good...). taking the stack trace, the first time i tried to save, OpenOffice showed an error dialog 'Error saving the document kvse5_flo.sxw: <newline> Nonexistent object. <newline> Nonexistent file.' (hasn't done that before); the second time it crashed again without any warnings (as descripted earlier)... [...] access("/home/fish/OpenOffice1.0/user/backup/sv3fo.tmp", F_OK) = 0 lstat("/home/fish/OpenOffice1.0/user/backup/sv3fo.tmp", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 access("/home/fish/OpenOffice1.0/user/backup/sv3fo.tmp", W_OK) = 0 access("/home/fish/OpenOffice1.0/user/backup/sv3fo.tmp", X_OK) = -1 EACCES (Permission denied) stat("/home/fish/OpenOffice1.0/user/backup/sv3fo.tmp", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 open("/home/fish/OpenOffice1.0/user/backup/sv3fo.tmp", O_RDONLY) = 25 brk(0x8120000) = 0x8120000 lseek(25, 0, SEEK_CUR) = 0 lseek(25, 0, SEEK_END) = 0 lseek(25, 0, SEEK_CUR) = 0 lseek(25, 0, SEEK_SET) = 0 time(NULL) = 1024490443 time(NULL) = 1024490443 gettimeofday({1024490443, 99624}, NULL) = 0 --- SIGSEGV (Segmentation fault) --- rt_sigaction(SIGABRT, {SIG_DFL}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 kill(4117, SIGABRT) = 0 --- SIGABRT (Aborted) --- +++ killed by SIGABRT +++
You provided a trace log of system calls. What I would like to have are the stacks of the active threads at the moment the office crashes. You get these by starting the office and afterwards attaching a debugger (e.g. gdb with gdb soffice.bin pid). When the office chrashes, the debugger prompts for user input. At this point please switch to the different threads and get stacktraces. Please attach this stacktraces to this bug.
*** Issue 5109 has been marked as a duplicate of this issue. ***
Hennes, can you please take a look at this and close it if it is not appropriate?
*** Issue 8899 has been marked as a duplicate of this issue. ***
From issue 8899, Linux, OOo 1.0.1: Able to open a file from a Cryptographic File System (cfs). But when I try to save the file or use "save as", the following error appears... Error saving the document [old document name] Nonexistent object. nonexistent file. Where I say "old document name" I note that the new name I specified in "save as" is not the one that shows up, rather the old name. For new documents this is "Untitled1" etc...
Reassigned
Hi Kay, in my opinion we cannot check every bug on every of the many unix/linux derivates with the many different possible file systems etc. That's why I suggest to reject this bug. Maybe some member of the OO community wants to investigate and fix it. It's your decision :-) Best Regards, Tino
Tino, if it is a bug it is a bug. And it at least has been reported another two times (5109, 8899), which I read as this not being to obscure. So, please investigate. You may also want to ask the community for support (e.g. dev@OOo).
I will try to investigate the problem until OO 6.1 Beta.
A crash should have the highest priority. I set it to P1.
I think the cause of this problem is that the osl_copyFile functions has bug. It calls an open(...) with the flag O_CREAT but doesn't provide a mode parameter.
Problem wasn´t reproducible when using staroffice 6.0 PP2 on SUSE Linux 8.1. User is able to open, edit and save files on a Cryptographic file system without getting an errormessage.
Fixed.
Fixed in sal02
Checked and verified in cws sal02 -> OK !
.