Apache OpenOffice (AOO) Bugzilla – Issue 106591
[Samba] Intermittent crash while not active window
Last modified: 2017-05-20 10:20:26 UTC
- Fedora 11 x86 (32bit) Over a period of 2 days, OO has crashed three times. I have one Writer and one Drawing window open each time. In each case the crash has occurred when OO was not the active application (ie topmost window). I'm filing this under Drawing because I usually don't use it and I've not seen these crashes before. Crash dump follows: (I) x.org loaded video driver of... (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so (II) Loading /usr/lib/xorg/modules/drivers//vesa_drv.so (II) Loading /usr/lib/xorg/modules/drivers//fbdev_drv.so (II) Unloading /usr/lib/xorg/modules/drivers//vesa_drv.so (II) Unloading /usr/lib/xorg/modules/drivers//fbdev_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.4.1-2.fc11-i586 (VI) kernel is: Linux 2.6.30.9-90.fc11.i586 #1 SMP Sat Oct 17 11:09:52 EDT 2009 i686 i686 i386 (VII) OpenOffice.org core rpm version is: openoffice.org-core-3.1.1-19.2.fc11-i586 (VIII) accessibility is: false (IX) gtk theme is: Nodoka (X) icon theme is: Fedora (XI) metacity theme is: Nodoka (XII) fedora release is: Fedora release 11 (Leonidas) (XIII) LANG is: en_US.UTF-8 ...start free space details ... Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg_dhcp197-lv_root 235129672 197294380 35449336 85% / /dev/mapper/vg_dhcp197-lv_root 235129672 197294380 35449336 85% / ...end free space details ... ...start (default) java details ... java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode) ...end (default) java details ... ...start sestatus details ... SELinux status: disabled ...end sestatus details ... ...start stackreport details ... 0x630dfe: 0x1c04d4: /usr/lib/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3 + 0x20dfe 0x631745: 0x1c04d4: /usr/lib/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3 + 0x21745 0x295400: 0x0: + 0x400 (__kernel_sigreturn + 0x0) 0x295422: 0x0: + 0x422 (__kernel_vsyscall + 0x2) 0x364d9b: 0x16cd7c: /lib/libc.so.6 + 0xced9b (__write + 0x4b) 0x62ff60: 0x1c04d4: /usr/lib/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3 + 0x1ff60 0x6301b3: 0x1c04d4: /usr/lib/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3 + 0x201b3 0x6302b6: 0x1c04d4: /usr/lib/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3 + 0x202b6 (osl_copyFile + 0x63) 0x463e0be: 0x4d730: /usr/lib/openoffice.org3/program/../basis-link/program/libucpfile1.so + 0x2c0be 0x462d17b: 0x4d730: /usr/lib/openoffice.org3/program/../basis-link/program/libucpfile1.so + 0x1b17b 0x462d60b: 0x4d730: /usr/lib/openoffice.org3/program/../basis-link/program/libucpfile1.so + 0x1b60b 0x4620754: 0x4d730: /usr/lib/openoffice.org3/program/../basis-link/program/libucpfile1.so + 0xe754 0x4621269: 0x4d730: /usr/lib/openoffice.org3/program/../basis-link/program/libucpfile1.so + 0xf269 0x45d8ab6: 0x3806c: /usr/lib/openoffice.org3/program/../basis-link/program/libucb1.so + 0x1eab6 0x45c2683: 0x3806c: /usr/lib/openoffice.org3/program/../basis-link/program/libucb1.so + 0x8683 0x8936ce: 0x6d4ec: /usr/lib/openoffice.org3/program/../basis-link/program/libucbhelper4gcc3.so + 0x1b6ce (ucbhelper::Content::transferContent(ucbhelper::Content const&, ucbhelper::InsertOperation, rtl::OUString const&, long) + 0x1fe) 0x24f10e2: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x1020e2 0x24f2a0c: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x103a0c 0x24f2c34: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x103c34 0x24f2ccc: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x103ccc 0x2515607: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x126607 0x251bf6a: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x12cf6a 0x251ed64: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x12fd64 0x251f145: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x130145 0x255baf1: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x16caf1 (SfxBaseModel::storeSelf(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 0x517) 0x2567bb0: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x178bb0 0x2528919: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x139919 0x25b80cc: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x1c90cc 0x25b841b: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x1c941b 0x25d63fb: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x1e73fb 0x25d63b1: 0x3c1660: /usr/lib/openoffice.org3/program/../basis-link/program/libsfxli.so + 0x1e73b1 0x192070a: 0x3852ec: /usr/lib/openoffice.org3/program/../basis-link/program/libvclli.so + 0x20670a 0x28021e7: 0x7c4e8: /usr/lib/openoffice.org/basis3.1/program/libvclplug_genli.so + 0x481e7 (SalDisplay::DispatchInternalEvent() + 0x97) 0x1fdbfab: 0x4f1d0: /usr/lib/openoffice.org/basis3.1/program/libvclplug_gtkli.so + 0x11fab 0x2338531: 0xde050: /lib/libglib-2.0.so.0 + 0x33531 0x233a308: 0xde050: /lib/libglib-2.0.so.0 + 0x35308 (g_main_context_dispatch + 0x1f8) 0x233d9e0: 0xde050: /lib/libglib-2.0.so.0 + 0x389e0 0x233db13: 0xde050: /lib/libglib-2.0.so.0 + 0x38b13 (g_main_context_iteration + 0x73) 0x1fdc073: 0x4f1d0: /usr/lib/openoffice.org/basis3.1/program/libvclplug_gtkli.so + 0x12073 0x2808775: 0x7c4e8: /usr/lib/openoffice.org/basis3.1/program/libvclplug_genli.so + 0x4e775 (X11SalInstance::Yield(bool, bool) + 0x2f) 0x17ab95a: 0x3852ec: /usr/lib/openoffice.org3/program/../basis-link/program/libvclli.so + 0x9195a (Application::Yield(bool) + 0x5c) 0x17ab9a9: 0x3852ec: /usr/lib/openoffice.org3/program/../basis-link/program/libvclli.so + 0x919a9 (Application::Execute() + 0x2b) 0x5c2ef5: 0x63b60: /usr/lib/openoffice.org3/program/../basis-link/program/libsofficeapp.so + 0x18ef5 0x17afaab: 0x3852ec: /usr/lib/openoffice.org3/program/../basis-link/program/libvclli.so + 0x95aab 0x17afc43: 0x3852ec: /usr/lib/openoffice.org3/program/../basis-link/program/libvclli.so + 0x95c43 (SVMain() + 0x2c) 0x5e71a8: 0x63b60: /usr/lib/openoffice.org3/program/../basis-link/program/libsofficeapp.so + 0x3d1a8 (soffice_main + 0xd0) 0x80487c4: 0xd04: /usr/lib/openoffice.org3/program/swriter.bin + 0x7c4 (main + 0x20) 0x2aca66: 0x16cd7c: /lib/libc.so.6 + 0x16a66 (__libc_start_main + 0xe6) 0x8048711: 0xd04: /usr/lib/openoffice.org3/program/swriter.bin + 0x711 ...end stackreport details ... ...start sample ldd details ... linux-gate.so.1 => (0x00ed1000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00110000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x006ca000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00694000) libgio-2.0.so.0 => /lib/libgio-2.0.so.0 (0x00553000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00f6f000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x005cd000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00ab3000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x005ea000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00a20000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0076c000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00b34000) libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x00929000) libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x00cca000) librt.so.1 => /lib/librt.so.1 (0x00f4a000) libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00665000) libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00ceb000) libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x007fe000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x0083f000) libvclplug_genli.so => /usr/lib/openoffice.org/basis3.1/program/libvclplug_genli.so (0x00bb4000) libvclli.so => /usr/lib/openoffice.org/basis3.1/program/libvclli.so (0xb7555000) libpspli.so => /usr/lib/openoffice.org/basis3.1/program/libpspli.so (0xb7477000) libsotli.so => /usr/lib/openoffice.org/basis3.1/program/libsotli.so (0x0092d000) libutlli.so => /usr/lib/openoffice.org/basis3.1/program/libutlli.so (0xb73ef000) libtlli.so => /usr/lib/openoffice.org/basis3.1/program/libtlli.so (0xb734d000) libcomphelp4gcc3.so => /usr/lib/openoffice.org/basis3.1/program/libcomphelp4gcc3.so (0xb7230000) libucbhelper4gcc3.so => /usr/lib/openoffice.org/basis3.1/program/libucbhelper4gcc3.so (0x00abe000) libuno_cppuhelpergcc3.so.3 => /usr/lib/openoffice.org/basis3.1/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 (0xb71a1000) libuno_cppu.so.3 => /usr/lib/openoffice.org/basis3.1/program/../ure-link/lib/libuno_cppu.so.3 (0x0098b000) libvos3gcc3.so => /usr/lib/openoffice.org/basis3.1/program/libvos3gcc3.so (0x009b7000) libuno_sal.so.3 => /usr/lib/openoffice.org/basis3.1/program/../ure-link/lib/libuno_sal.so.3 (0xb6fda000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00684000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6eab000) libXext.so.6 => /usr/lib/libXext.so.6 (0x006b1000) libdl.so.2 => /lib/libdl.so.2 (0x00cbc000) libpthread.so.0 => /lib/libpthread.so.0 (0x00a66000) libstlport_gcc.so => /usr/lib/openoffice.org/basis3.1/program/../ure-link/lib/libstlport_gcc.so (0xb6de7000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6cf8000) libm.so.6 => /lib/libm.so.6 (0x00a81000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00db9000) libc.so.6 => /lib/libc.so.6 (0xb6b87000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00fce000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x006c1000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x0068c000) libXi.so.6 => /usr/lib/libXi.so.6 (0x0091e000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x009da000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x0068f000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x009e4000) libselinux.so.1 => /lib/libselinux.so.1 (0x00b67000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00b85000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6b3f000) libz.so.1 => /lib/libz.so.1 (0xb6b2b000) libexpat.so.1 => /lib/libexpat.so.1 (0xb6b04000) /lib/ld-linux.so.2 (0x009f2000) libcap.so.2 => /lib/libcap.so.2 (0x009e7000) libi18npaperli.so => /usr/lib/openoffice.org/basis3.1/program/libi18npaperli.so (0x009ec000) libbasegfxli.so => /usr/lib/openoffice.org/basis3.1/program/libbasegfxli.so (0xb6a83000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00a14000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb6a69000) libi18nisolang1gcc3.so => /usr/lib/openoffice.org/basis3.1/program/libi18nisolang1gcc3.so (0x00f14000) libi18nutilgcc3.so => /usr/lib/openoffice.org/basis3.1/program/libi18nutilgcc3.so (0xb6a57000) libicuuc.so.40 => /usr/lib/libicuuc.so.40 (0xb691b000) libicudata.so.40 => /usr/lib/libicudata.so.40 (0xb5bd4000) libicule.so.40 => /usr/lib/libicule.so.40 (0xb5b9f000) libjvmaccessgcc3.so.3 => /usr/lib/openoffice.org/basis3.1/program/../ure-link/lib/libjvmaccessgcc3.so.3 (0x00aa9000) libuno_salhelpergcc3.so.3 => /usr/lib/openoffice.org/basis3.1/program/../ure-link/lib/libuno_salhelpergcc3.so.3 (0x00a1c000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb5b6d000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb5b51000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00ab0000) libattr.so.1 => /lib/libattr.so.1 (0x00b2d000) libuuid.so.1 => /lib/libuuid.so.1 (0x00bac000) libfreebl3.so => /lib/libfreebl3.so (0xb5b08000) ...end sample ldd details ...
Created attachment 65899 [details] Drawing file loaded at time of crash
I do not reproduce the crash with OOo 3.1.1 (vanilla FR/US version) under Ubuntu 8.04. Please test this : - remove (or only rename) your personal settings OOo directory ~/.openoffice.org to force OOo to create a new one with default parameters - try vanilla version from http://download.openoffice.org (remove distribution version first).
dtardon->andrewkreid: Is at least one of the opened files on nonlocal filesystem, like samba share? The stack is definitely the same as in https://bugzilla.redhat.com/show_bug.cgi?id=529648 . The crash is probably trigerred by autosave in your case. dtardon->mhu: The crash is due to SIGBUS in write syscall in oslDoCopyFile, if it rings a bell.
Created attachment 65908 [details] backtrace
Created attachment 65909 [details] full backtrace
This simply crashes in the base "write" call of nRet = write(DestFileFD,pSourceFile,nSourceSize); right ? Does anyone who gets this get any e.g. error messages on either the local /var/log/messages of maybe the remote server's samba log ?, it all looks a little odd to me.
The save is indeed to a Samba share. I'll endeavour to reproduce tomorrow.
dtardon->cmc: I'd say the write call itself is okay; it's the mmaped memory it uses that is culprit here... From mmap(2): "Use of a mapped region can result in these signals: SIGSEGV Attempted write into a region mapped as read-only. SIGBUS Attempted access to a portion of the buffer that does not corre- spond to the file (for example, beyond the end of the file, including the case where another process has truncated the file)." It's not problem in the samba share itself, my standalone test program can copy a mmapped file without any problems.
Created attachment 65913 [details] smb.conf
Created attachment 65915 [details] log.smbd
Created attachment 65916 [details] log.ip-address
I've it mounted on the client as: mount -t cifs -o user=dtardon,pass=password,domain=MYGROUP,uid=dtardon,gid=dtardon,file_mode=0644,dir_mode=0755 //samba-server/work /mnt/work
Did some more experimentation today by loading the attached odg file into OO, setting autosave to 2 minutes and leaving it alone apart from making trivial modifications to the drawing every now and then. I had 2 more crashes over the course of ~3 hours (same stacktrace as before) while the file was loaded from a Samba share. Switched to loading the same file from local disk. Have had no crashes in about 4 hours.
*** Issue 107192 has been marked as a duplicate of this issue. ***
mav->dtardon: How big was the file, you have tried to transport in your test program? On our system, where the problem could be reproduced, the mmap() seems to have a problem after the first memory-page is full.
dtardon->mav: I think I tried small files only, 1-2 KB of size.
Reassigned.
@dtardon could you please test your mount command with the 'nobrl' and maybe 'noserverino' parameters also? more information can be found in man mount.cifs(8) Regards Lars
The problem here was that the file was locked while using mmap. In case a file from the problematic location is locked it can be opened read-only again successfully, but... it is not possible to read from the file descriptor! As result mmap does not provide any data. From my point of view it is a bug in the smb-client implementation, even probably two of them: - the open() call should return error if the file is not really accessible - mmap should return error if the data can not be mapped successfuly The fix for issue 104974 contains workaround for the problem, so I close this issue as a duplicate to issue 104974. *** This issue has been marked as a duplicate of 104974 ***
duplicate -< closed
This bug is not fixed, on my System (Gentoo) I can reproduce the behaviour. Office crash (calls Document Recovery) I mount a smb share with: 1. mount //Windows/home /mnt/Windows/ -t cifs -o domain=<workgroup>,credentials=/etc/autofs/smbfs_user,uid=<user>,gid=<group>,rw,file_mode=0664,dir_mode=0775 Replace the <...> with your values. 2. chdir to /mnt/Windows/... open an office from shell like: 3. /path/to/office/soffice odf-file You will got the Document Recovery. Close the office, chdir to '/' unmount the /mnt/Windows mount the path again with additional options: ',nobrl' (without quotes) maybe you need ',noserverino' also. go back to point 2. Now the document should open.
This issue is not duplicate to https://so-web.germany.sun.com/iBIS/servlet/edit.ControlPanel?tid=i104974
Ok, so the workaround does not help always. Taking the issue over and adjusting the target.
I have tried sendfile() as mhu has suggested and it looks to work well and is able to workaround the crash. As I understood, sendfile is mmap based, so it should contain a workaround for the problem I assume. So it could probably make sense to integrate the solution based on sendfile() in OOo3.3. Even if we decide not to go this way, the implementation must set read lock on the file before using mmap ( or sendfile ), the locking will definitely solve the problem as well, even without switching to sendfile.
Are you sure about sendfile ?, I thought that somewhere along the line sendfile was changed to only work on sending to a fd belonging to a network socket and not a real file
mav->cmc: No, I am not sure about sendfile, this is why I have written "could probably make sense". ;) Even possibility of the mentioned change in behavior can be treated a minus of the "sendfile()". Anyway, before introducing this we have to check all the supported OS's to be sure that it works there as expected. But in case it works there as expected it could be an option.
Unfortunately under Linux I'm "fairly" sure sendfile doesn't work with an arbitrary non-socket destination, though it did at some stage in the past. I'd just go with ye-old read/write with a big buffer myself.
*** Issue 108318 has been marked as a duplicate of this issue. ***
Sorry for the late answer. Read/write with a big buffer would work good, but slower. And I am not completely sure that it is correct to sacrifice performance because of a problem in smb-client implementation.
I wonder if the difference is measurable. Lots on conflicting evidence on mmap vs a read/write for a simple linear copy. I remember digging into coreutils for the canonical "cp" implementation etc. and it, as an example of something that might be expected to be optimized to within an inch of its life, didn't attempt a mmap IIRC.
I am not sure what you mean by canonical cp implementation. If I remember correctly, when I have investigated the problem on one of our linux systems, the cp command had just the same problems and had also crashed. But I did not investigate it deep, so it could be that the reason for the crash was something different. I will try performance test with the copy/paste solution to see how it looks on our test-platforms. Anyway, I am still not convinced that it is correct to sacrifice possible performance benefits only to workaround an obvious bug in smb-client.
Sure, I've sympathy with that position. Its definitely a bug in someone elses code, and if we didn't do anything about it at all that would be a reasonable position, but the vaguely related workaround char nCh; if ( 1 != read( SourceFileFD, &nCh, 1 ) || -1 == lseek( SourceFileFD, 0, SEEK_SET ) ) undermines that logic a little :-)
:) You are right, the current workaround is also definitely not nice, and I do not believe that it would be correct to let it stay as it is. I am just not sure that using of read/write always is a good replacement. Although it has of course a big plus in its simplicity.
Actually if we want to change it for OOo3.3, the only acceptable solution would be read/write replacement suggested by cmc. It is too late to introduce something more complex. And the change would anyway affect only Unix platforms. mav->cmc: If the problem is important enough to be addressed as showstopper I have nothing against integrating the copy/paste solution for 3.3 temporarily.
Personally I'd go with the buffer read/write. There's a depressing lack of activity from our samba/kernel people to even have look into whether its a samba client issue, a kernel issue or a samba server issue which is at the root of the odd mmap bustage, i.e. see https://bugzilla.redhat.com/show_bug.cgi?id=601621
mav->cmc: We need to declare the issue as a showstopper to integrate the change in OOo3.3, could you please do it? Or would it be acceptable if I integrate it in OOo3.4 ( before it will be probably replaced with a better one, just for the case that there will be again no time to look for something, that is better )?
With my Red Hat hat on, this is a samba/kernel team bug, someone else broken it so they should get to fix it. If OOo works around it then in six months time noone will able to reproduce it and it'll probably be declared "works for me", get closed and the underlying bug will remain. With the other probability that in the meantime a non-crashing vanilla 3.3 will be compared to a crashing fedora 3.2.1 and the irritating CrazyDistroDefense will be used against me. With my OpenOffice.org hat on, it's clear that there's a bug out there in the wild where OOo will get the blame for crashing. *drums fingers*, bah, we should probably workaround it in OOo anyway.
Ok, changing the target to 3.4 then.
The related bug report from RedHat (#601621) states that this is not a kernel issue, which leaves me a little bit puzzled about the source of this problem. I really don't have any opinions on the responsibilities for this issue, but I'm growing desperate to see it getting fixed. For me this thing has become a real issue, causing users to keep local copies of shared documents (since they cannot work with the ones on the SMB share anymore) leading to more and more consistency/versioning problems. Waiting another 6 month to get it fixed would be really tough. If there is any additional information that I could provide to sort this out, please let me know.
The fix is commited in fwk149 now.
mav->lla: Do you still have the environment to verify the issue in fwk149?
verified. Some background: Check machine was a Gentoo Linux with kernel 2.6.33, samba 3.0.37. On this machine a office DEV300m90 crashes repeatable, but not this CWS. A snarly effect, after a document could load right with the cws version, it is also loadable without crash in the DEV300m90 version. Only a full reinstall helps to repeat the crash. On an up to date Gentoo Linux with kernel 2.6.35.7, samba 3.4.9. A office DEV300m90 do not crash.