Download it now!
Bug 54827 - FILEOPEN: File open from NTFS Filesystem- crashes Write -version 3.6 ,3..6.1
Summary: FILEOPEN: File open from NTFS Filesystem- crashes Write -version 3.6 ,3..6.1
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.0.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-09-12 21:33 UTC by Mas
Modified: 2012-10-02 04:54 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
valgrind debug log (74.96 KB, text/plain)
2012-09-18 18:20 UTC, Mas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mas 2012-09-12 21:33:20 UTC
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
Comment 1 Mas 2012-09-12 21:36:02 UTC
Issues has been confirmed
Comment 2 Michael Meeks 2012-09-13 09:35:00 UTC
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 !
Comment 3 Mas 2012-09-15 21:54:04 UTC
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
Comment 4 Michael Meeks 2012-09-17 09:32:48 UTC
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 ! :-)
Comment 5 Mas 2012-09-18 18:20:02 UTC
Created attachment 67346 [details]
valgrind debug log

Valgrind log attached
Comment 6 Mas 2012-09-18 18:23:42 UTC
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.
Comment 7 Michael Meeks 2012-09-26 12:58:17 UTC
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 ?
Comment 8 Mas 2012-10-02 04:54:14 UTC
i will test this with gedit