Problem description: Steps to reproduce: When I start Writer (in Ubuntu), and choose File|Open, I am able to see and select files on the NTFS drives, but when I select one to open, Writer simply disappears. I am assuming that this is because the particular NTFS drive is not mounted in Ubuntu yet, although it shows up in Writer as well as Nautilus. If I do this a second time, it works fine and the file is loaded. At this point, Nautilus shows the symbol next to the drive indicating that it has been mounted. Current behavior: Writer crashes when opening a file from a mounted partition the first time. After reopening Writer the file is recovered and can be viewed. Expected behavior: For the file to be opened Platform (if different from the browser): Ubuntu 12.04 with Libreoffice 3.6 and 3.6.1 Mailing list thread for more information http://nabble.documentfoundation.org/Opening-Files-in-Writer-td4006889.html#a4006989
Issues has been confirmed
fun :-) can you get an strace of the first-time case when it fails ? run: strace -f -s 256 -o /tmp/slog soffice then when it's failed ctrl-c it ASAP; and gzip /tmp/slog and attach it if you can - otherwise mail it to me :-) Thanks !
The ubuntu crash log and stack trace can be downloaded from http://treogrp.com/bugs/libreoffice/stacktrace/crash_stack-libreebug54827.zip The file was too large to attach to this bug ticket. This was done using Ubuntu 12.04 and Libreoffice 3.6.1
This is the problem: 27507 inotify_rm_watch(27, 7) = 0 27507 open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = 45 27507 writev(45, [{"*** glibc detected *** ", 23}, {"/usr/lib/libreoffice/program/soffice.bin", 40}, {": ", 2}, {"free(): invalid pointer", 23}, {": 0x", 4}, {"00007f385000a050", 16}, {" ***\n", 5}], 7) = 113 27507 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f387a358000 27507 futex(0x7f387964ddf0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 27507 write(45, "======= Backtrace: =========\n", 29) = 29 Some memory corruption, apparently related to the gtk+2 file-selector on Ubuntu. Mas: can you install the libreoffice and gtk+ / glib debuginfo packages: otherwise traces are pretty useless :-) Then we'll need you to run libreoffice under valgrind: valgrind --trace-children=yes soffice >& /tmp/val-log And attach the val-log as/when you've crashed it. Thanks ! :-)
Created attachment 67346 [details] valgrind debug log Valgrind log attached
During the run of vlagrind. The writer application crashed but was able to recover and continue running. I am assuming because the app was running slower then usual in debug mode.
All the valgrind badness shows things like this: ==17534== Invalid read of size 8 ==17534== at 0x5BB801F: wcslen (wcslen.S:48) ==17534== by 0x5BC13FE: wcsxfrm_l (strxfrm_l.c:107) ==17534== by 0x161F07BE: g_utf8_collate_key (gunicollate.c:399) ==17534== by 0x161F0A0F: g_utf8_collate_key_for_filename (gunicollate.c:671) ==17534== by 0x142F274D: file_system_model_set (gtkfilechooserdefault.c:6645) ==17534== by 0x14309258: _gtk_file_system_model_get_value (gtkfilesystemmodel.c:1606) ==17534== by 0x142F7CFF: name_sort_func (gtkfilechooserdefault.c:6045) ==17534== by 0x1430732F: compare_array_element (gtkfilesystemmodel.c:697) ==17534== by 0x161D4283: msort_with_tmp (gqsort.c:154) ==17534== by 0x161D3FF3: msort_with_tmp (gqsort.c:87) ==17534== by 0x161D4003: msort_with_tmp (gqsort.c:88) ==17534== by 0x161D3FF3: msort_with_tmp (gqsort.c:87) ==17534== Address 0x215ec818 is 40 bytes inside a block of size 44 alloc'd ==17534== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==17534== by 0x161CCA78: g_malloc (gmem.c:159) ==17534== by 0x161F1381: _g_utf8_normalize_wc (gunidecomp.c:398) ==17534== by 0x161F078A: g_utf8_collate_key (gunicollate.c:395) ==17534== by 0x161F0A0F: g_utf8_collate_key_for_filename (gunicollate.c:671) ==17534== by 0x142F274D: file_system_model_set (gtkfilechooserdefault.c:6645) ==17534== by 0x14309258: _gtk_file_system_model_get_value (gtkfilesystemmodel.c:1606) ==17534== by 0x142F7CFF: name_sort_func (gtkfilechooserdefault.c:6045) ==17534== by 0x1430732F: compare_array_element (gtkfilesystemmodel.c:697) ==17534== by 0x161D4283: msort_with_tmp (gqsort.c:154) Which are in the gtk+ file-selector. I guess this is a memory corruption there; though you'd prolly need to get more callers to get something helpful: re-running valgrind (sorry it's slow) with --num-callers=40 or somesuch would prolly give a more helpful trace. I see file-selector related crashes too from time to time but relatively few. Bjoern - I guess it's a generic Ubuntu bug we can't switch across. Mas - can you confirm you have the same problems in file-roller or gedit or whatever ?
i will test this with gedit