Bug 1444437 - Segmentation fault when presentation is opened two times in a row
Summary: Segmentation fault when presentation is opened two times in a row
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-documents
Version: 7.4
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Debarshi Ray
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-21 10:31 UTC by Martin Krajnak
Modified: 2017-08-01 10:01 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-08-01 10:01:37 UTC


Attachments (Terms of Use)
crash log (32.86 KB, text/plain)
2017-04-21 10:31 UTC, Martin Krajnak
no flags Details
odp file (641.96 KB, application/vnd.oasis.opendocument.presentation)
2017-04-21 10:32 UTC, Martin Krajnak
no flags Details
ppt (232.00 KB, application/x-ole-storage)
2017-04-21 10:34 UTC, Martin Krajnak
no flags Details
pptx (261.35 KB, application/zip)
2017-04-21 10:34 UTC, Martin Krajnak
no flags Details
rhel short log (1.66 KB, text/plain)
2017-04-26 09:05 UTC, Martin Krajnak
no flags Details
fedora25 short log (1.12 KB, text/plain)
2017-04-26 09:08 UTC, Martin Krajnak
no flags Details
gnome-document patch to shutdown lok promptly (1.58 KB, patch)
2017-05-08 16:03 UTC, Caolan McNamara
no flags Details | Diff
libreoffice part of it (13.55 KB, application/mbox)
2017-05-08 16:05 UTC, Caolan McNamara
no flags Details
backports to rhel-7 of libreoffice side (38.21 KB, application/mbox)
2017-05-11 08:03 UTC, Caolan McNamara
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2312 normal SHIPPED_LIVE gnome-documents, gnome-online-miners, libgepub bug fix and enhancement update 2017-08-01 12:42:56 UTC
GNOME Bugzilla 782508 None None None 2019-06-10 10:06 UTC

Description Martin Krajnak 2017-04-21 10:31:46 UTC
Created attachment 1273295 [details]
crash log

Description of problem:
Opening presentation in any of formats - ppt, pptx or odp leads to crash with segmentation fault


Version-Release number of selected component (if applicable):
gnome-documents-3.22.2-2.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1.Open documents
2.Open any of attached files
3.Go back to all documents
4.Open any of the attached files or same one again,

Actual results:
Crash - see provided log

Expected results:
Application should not crash and should render the file.

Comment 1 Martin Krajnak 2017-04-21 10:32 UTC
Created attachment 1273296 [details]
odp file

Comment 2 Martin Krajnak 2017-04-21 10:34 UTC
Created attachment 1273297 [details]
ppt

Comment 3 Martin Krajnak 2017-04-21 10:34 UTC
Created attachment 1273298 [details]
pptx

Comment 4 Debarshi Ray 2017-04-24 18:47:54 UTC
This incomplete line makes it look as if it crashed from inside libreoffice:
** (org.gnome.Documents:11354): INFO: LOKDocView_Impl::globalCallbac

It will be helpful to have the backtrace from the crash. Since gnome-documents is run by the gjs interpreter, you need to do the following to attach gdb to it, and then reproduce the crash:

In one terminal:
$ gnome-documents

In another terminal:
$ ps aux | grep gnome-documents
$ gdb /usr/bin/gjs-console <above PID>

Then trigger the crash, and get the backtrace from gdb as:
(gdb) thread apply all bt

It will be useful to know if you can reproduce the same crash on Fedora 25 with gnome-documents-3.22.3:
https://koji.fedoraproject.org/koji/buildinfo?buildID=881739

Since libreoffice's LOKDocView widget was backported to RHEL 7.4, it might be a bug in libreoffice too. Not sure, yet.

Comment 5 Martin Krajnak 2017-04-26 08:58:10 UTC
rhel 7 gnome-documents-3.22.2-2.el7.x86_64

Program received signal SIGSEGV, Segmentation fault.
0x00007fdaa6249fc0 in SfxShell::GetViewShell() const () from /usr/lib64/libreoffice/program/libsfxlo.so

gnome-documents-3.22.3-1.fc25.x86_64 looks similar

[Thread 0x7fbd7950b700 (LWP 28374) exited]

Thread 1 "gnome-documents" received signal SIGSEGV, Segmentation fault.
0x00007fbd8b70ae00 in SfxShell::GetViewShell() const ()
   from /usr/lib64/libreoffice/program/libsfxlo.so


I also attaching some logs if needed.
So what we can make of this, is this a flaw in libreoffice ?

Comment 6 Martin Krajnak 2017-04-26 09:05 UTC
Created attachment 1274142 [details]
rhel short log

Comment 7 Martin Krajnak 2017-04-26 09:08 UTC
Created attachment 1274143 [details]
fedora25 short log

Comment 8 Debarshi Ray 2017-04-26 19:40:39 UTC
Ok, I can reproduce it even on Fedora 25. I see that it only crashes with ODPs, PPTs and PPTXs. I couldn't reproduce it with an ODT file. This makes me suspect that the problem lies in libreoffice.

Comment 9 Debarshi Ray 2017-04-26 19:46:17 UTC
Here is the complete backtrace (thanks to coredumpctl):

Core was generated by `/usr/bin/gjs-console /usr/bin/gnome-documents'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  SfxShell::GetViewShell (this=0x0) at /usr/src/debug/libreoffice-5.2.6.2/sfx2/source/control/shell.cxx:133
133	    return pImpl->pViewSh;
[Current thread is 1 (Thread 0x7f31fe0b2a80 (LWP 28004))]
(gdb) thread apply all bt

Thread 12 (Thread 0x7f31d071e700 (LWP 28097)):
#0  0x00007f31f9516bf9 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f31fb323afa in g_cond_wait_until (cond=cond@entry=0x55b64fef1e78, mutex=mutex@entry=0x55b64fef1e70, end_time=end_time@entry=122246121888) at gthread-posix.c:1442
#2  0x00007f31fb2b28c9 in g_async_queue_pop_intern_unlocked (queue=0x55b64fef1e70, wait=wait@entry=1, end_time=122246121888) at gasyncqueue.c:422
#3  0x00007f31fb2b2f28 in g_async_queue_timeout_pop_unlocked (queue=<optimized out>, timeout=timeout@entry=500000)
    at gasyncqueue.c:570
#4  0x00007f31fb306566 in g_thread_pool_wait_for_new_task (pool=<optimized out>) at gthreadpool.c:262
#5  0x00007f31fb306566 in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:296
#6  0x00007f31fb305b93 in g_thread_proxy (data=0x55b651e6b990) at gthread.c:784
#7  0x00007f31f97e26ca in start_thread (arg=0x7f31d071e700) at pthread_create.c:333
#8  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 11 (Thread 0x7f31cebd3700 (LWP 28085)):
#0  0x00007f31f97e8809 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00007f31cf17aeab in rtl_cache_wsupdate_wait (seconds=10)
    at /usr/src/debug/libreoffice-5.2.6.2/sal/rtl/alloc_cache.cxx:1335
#2  0x00007f31cf17aeab in rtl_cache_wsupdate_all(void*) (arg=0xa)
    at /usr/src/debug/libreoffice-5.2.6.2/sal/rtl/alloc_cache.cxx:1483
#3  0x00007f31f97e26ca in start_thread (arg=0x7f31cebd3700) at pthread_create.c:333
#4  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 10 (Thread 0x7f31e3198700 (LWP 28010)):
#0  0x00007f31f9516bf9 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f31fb323afa in g_cond_wait_until (cond=cond@entry=0x55b64fef1e78, mutex=mutex@entry=0x55b64fef1e70, end_time=end_time@entry=122246077313) at gthread-posix.c:1442
#2  0x00007f31fb2b28c9 in g_async_queue_pop_intern_unlocked (queue=0x55b64fef1e70, wait=wait@entry=1, end_time=122246077313) at gasyncqueue.c:422
#3  0x00007f31fb2b2f28 in g_async_queue_timeout_pop_unlocked (queue=<optimized out>, timeout=timeout@entry=500000)
    at gasyncqueue.c:570
#4  0x00007f31fb306566 in g_thread_pool_wait_for_new_task (pool=<optimized out>) at gthreadpool.c:262
#5  0x00007f31fb306566 in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:296
#6  0x00007f31fb305b93 in g_thread_proxy (data=0x55b65041b5e0) at gthread.c:784
#7  0x00007f31f97e26ca in start_thread (arg=0x7f31e3198700) at pthread_create.c:333
#8  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 9 (Thread 0x7f31e6b4a700 (LWP 28009)):
#0  0x00007f31f951101d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f31fb2de166 in g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0x55b650146fe0, timeout=<optimized out>, context=0x55b650146f20) at gmain.c:4228
#2  0x00007f31fb2de166 in g_main_context_iterate (context=context@entry=0x55b650146f20, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3924
#3  0x00007f31fb2de27c in g_main_context_iteration (context=0x55b650146f20, may_block=1) at gmain.c:3990
#4  0x00007f31e6b51fad in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#5  0x00007f31fb305b93 in g_thread_proxy (data=0x55b650303680) at gthread.c:784
#6  0x00007f31f97e26ca in start_thread (arg=0x7f31e6b4a700) at pthread_create.c:333
#7  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 8 (Thread 0x7f31c0126700 (LWP 28098)):
#0  0x00007f31f9516bf9 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f31fb323afa in g_cond_wait_until (cond=cond@entry=0x55b6528facc8, mutex=mutex@entry=0x55b6528facc0, end_time=end_time@entry=122246150233) at gthread-posix.c:1442
#2  0x00007f31fb2b28c9 in g_async_queue_pop_intern_unlocked (queue=0x55b6528facc0, wait=wait@entry=1, end_time=122246150233) at gasyncqueue.c:422
#3  0x00007f31fb2b2f28 in g_async_queue_timeout_pop_unlocked (queue=<optimized out>, timeout=timeout@entry=500000)
    at gasyncqueue.c:570
#4  0x00007f31fb306566 in g_thread_pool_wait_for_new_task (pool=<optimized out>) at gthreadpool.c:262
#5  0x00007f31fb306566 in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:296
#6  0x00007f31fb305b93 in g_thread_proxy (data=0x55b650746f70) at gthread.c:784
#7  0x00007f31f97e26ca in start_thread (arg=0x7f31c0126700) at pthread_create.c:333
#8  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 7 (Thread 0x7f31e938c700 (LWP 28008)):
#0  0x00007f31f951101d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f31fb2de166 in g_main_context_poll (priority=<optimized out>, n_fds=4, fds=0x55b650cc8860, timeout=<optimized out>, context=0x55b64fef4400) at gmain.c:4228
#2  0x00007f31fb2de166 in g_main_context_iterate (context=0x55b64fef4400, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3924
#3  0x00007f31fb2de4f2 in g_main_loop_run (loop=0x55b64fef2850) at gmain.c:4125
#4  0x00007f31fb8c2a76 in gdbus_shared_thread_func (user_data=0x55b64fef2890) at gdbusprivate.c:247
#5  0x00007f31fb305b93 in g_thread_proxy (data=0x55b64fef3ca0) at gthread.c:784
#6  0x00007f31f97e26ca in start_thread (arg=0x7f31e938c700) at pthread_create.c:333
#7  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 6 (Thread 0x7f31e9b8d700 (LWP 28007)):
#0  0x00007f31f951101d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f31fb2de166 in g_main_context_poll (priority=<optimized out>, n_fds=2, fds=0x55b64fef2260, timeout=<optimized out>, context=0x55b64fef1f80) at gmain.c:4228
#2  0x00007f31fb2de166 in g_main_context_iterate (context=context@entry=0x55b64fef1f80, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3924
#3  0x00007f31fb2de27c in g_main_context_iteration (context=0x55b64fef1f80, may_block=may_block@entry=1)
    at gmain.c:3990
#4  0x00007f31fb2de2c1 in glib_worker_main (data=<optimized out>) at gmain.c:5783
#5  0x00007f31fb305b93 in g_thread_proxy (data=0x55b64fef3c50) at gthread.c:784
#6  0x00007f31f97e26ca in start_thread (arg=0x7f31e9b8d700) at pthread_create.c:333
#7  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 5 (Thread 0x7f31ce3d2700 (LWP 28086)):
#0  0x00007f31f951101d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f31ca569a64 in poll (__timeout=71, __nfds=1, __fds=0x7f31ce3d16a0) at /usr/include/bits/poll2.h:46
#2  0x00007f31ca569a64 in SvpSalInstance::DoReleaseYield(int) (this=0x55b652486260, nTimeoutMS=71)
    at /usr/src/debug/libreoffice-5.2.6.2/vcl/headless/svpinst.cxx:388
#3  0x00007f31ca569e0e in SvpSalInstance::DoYield(bool, bool, unsigned long) (this=0x55b652486260, bWait=<optimized out>, bHandleAllCurrentEvents=<optimized out>, nReleased=<optimized out>)
    at /usr/src/debug/libreoffice-5.2.6.2/vcl/headless/svpinst.cxx:370
#4  0x00007f31ca4cd6e1 in ImplYield(bool, bool, unsigned long) (nReleased=0, i_bAllEvents=false, i_bWait=<optimized out>) at /usr/src/debug/libreoffice-5.2.6.2/vcl/source/app/svapp.cxx:511
#5  0x00007f31ca4cd6e1 in Application::Yield() () at /usr/src/debug/libreoffice-5.2.6.2/vcl/source/app/svapp.cxx:556
#6  0x00007f31ca4cfc65 in Application::Execute() ()
    at /usr/src/debug/libreoffice-5.2.6.2/vcl/source/app/svapp.cxx:473
#7  0x00007f31e090475c in desktop::Desktop::DoExecute() ()
    at /usr/src/debug/libreoffice-5.2.6.2/desktop/source/app/app.cxx:1318
#8  0x00007f31e090475c in desktop::Desktop::Main() (this=0x7f31ce3d1af0)
    at /usr/src/debug/libreoffice-5.2.6.2/desktop/source/app/app.cxx:1648
#9  0x00007f31ca4d34f6 in ImplSVMain() () at /usr/src/debug/libreoffice-5.2.6.2/vcl/source/app/svmain.cxx:185
#10 0x00007f31ca4d35f2 in SVMain() () at /usr/src/debug/libreoffice-5.2.6.2/vcl/source/app/svmain.cxx:223
#11 0x00007f31e092e29a in soffice_main() ()
    at /usr/src/debug/libreoffice-5.2.6.2/desktop/source/app/sofficemain.cxx:166
#12 0x00007f31cf19f027 in osl_thread_start_Impl(void*) (pData=0x55b652485f90)
    at /usr/src/debug/libreoffice-5.2.6.2/sal/osl/unx/thread.cxx:240
#13 0x00007f31f97e26ca in start_thread (arg=0x7f31ce3d2700) at pthread_create.c:333
#14 0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 4 (Thread 0x7f31d3ea3700 (LWP 28028)):
#0  0x00007f31f97e8460 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f31f9fce50c in __gthread_cond_wait (__mutex=<optimized out>, __cond=<optimized out>)
    at /usr/src/debug/gcc-6.3.1-20161221/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/x86_64-redhat-linux/bits/gthr-default.h:864
#2  0x00007f31f9fce50c in std::condition_variable::wait(std::unique_lock<std::mutex>&) (this=<optimized out>, __lock=...) at ../../../../../libstdc++-v3/src/c++11/condition_variable.cc:53
#3  0x00007f31dc0d3006 in bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::threadRunLoop() ()
    at /lib64/libjavascriptcoregtk-4.0.so.18
#4  0x00007f31dc0d3139 in  () at /lib64/libjavascriptcoregtk-4.0.so.18
#5  0x00007f31f9fd45cf in std::execute_native_thread_routine(void*) (__p=0x55b64fed4e60)
    at ../../../../../libstdc++-v3/src/c++11/thread.cc:83
#6  0x00007f31f97e26ca in start_thread (arg=0x7f31d3ea3700) at pthread_create.c:333
#7  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 3 (Thread 0x7f31eb49b700 (LWP 28005)):
#0  0x00007f31f97e8460 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f31f43b3d30 in PR_WaitCondVar (cvar=0x55b64fe3cee0, timeout=timeout@entry=4294967295)
    at ../../../nspr/pr/src/pthreads/ptsynch.c:396
#2  0x00007f31fad0e5ae in js::GCHelperThread::threadLoop() (this=0x55b64fe40d78)
    at /usr/src/debug/mozjs-24.2.0/js/src/jsgc.cpp:2266
#3  0x00007f31f43b95bc in _pt_root (arg=0x55b64fe53300) at ../../../nspr/pr/src/pthreads/ptthread.c:216
#4  0x00007f31f97e26ca in start_thread (arg=0x7f31eb49b700) at pthread_create.c:333
#5  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 2 (Thread 0x7f31eac9a700 (LWP 28006)):
#0  0x00007f31f97e8460 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f31f43b3d30 in PR_WaitCondVar (cvar=0x55b64fe5cc50, timeout=timeout@entry=4294967295)
    at ../../../nspr/pr/src/pthreads/ptsynch.c:396
#2  0x00007f31fad81feb in js::SourceCompressorThread::threadLoop() (this=0x55b64fe40e58)
    at /usr/src/debug/mozjs-24.2.0/js/src/jsscript.cpp:1094
#3  0x00007f31fad81feb in js::SourceCompressorThread::compressorThread(void*) (arg=0x55b64fe40e58)
    at /usr/src/debug/mozjs-24.2.0/js/src/jsscript.cpp:965
#4  0x00007f31f43b95bc in _pt_root (arg=0x55b64fe5ccf0) at ../../../nspr/pr/src/pthreads/ptthread.c:216
#5  0x00007f31f97e26ca in start_thread (arg=0x7f31eac9a700) at pthread_create.c:333
#6  0x00007f31f951cf7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 1 (Thread 0x7f31fe0b2a80 (LWP 28004)):
#0  0x00007f31cc8b5290 in SfxShell::GetViewShell() const (this=0x0)
    at /usr/src/debug/libreoffice-5.2.6.2/sfx2/source/control/shell.cxx:133
#1  0x00007f31c1a327d9 in sd::ViewShell::GetViewFrame() const (this=<optimized out>)
    at /usr/src/debug/libreoffice-5.2.6.2/sd/source/ui/view/viewshel.cxx:130
#2  0x00007f31c19590dd in SdXImpressDocument::initializeForTiledRendering(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x7f31c2764358, rArguments=empty uno::Sequence)
    at /usr/src/debug/libreoffice-5.2.6.2/sd/source/ui/unoidl/unomodel.cxx:2385
#3  0x00007f31e0949f90 in doc_initializeForRendering(LibreOfficeKitDocument*, char const*) (pThis=<optimized out>, pArguments=<optimized out>) at /usr/src/debug/libreoffice-5.2.6.2/desktop/source/lib/init.cxx:1130
#4  0x00007f31e0b8a044 in postDocumentLoad(gpointer) (pData=0x55b650d4a130)
    at /usr/src/debug/libreoffice-5.2.6.2/libreofficekit/source/gtk/lokdocview.cxx:833
#5  0x00007f31fd0eee78 in gdk_threads_dispatch () at /lib64/libgdk-3.so.0
#6  0x00007f31fb2da8e7 in g_idle_dispatch (source=0x55b6518938d0, callback=0x7f31fd0eee50 <gdk_threads_dispatch>, user_data=0x55b650254100) at gmain.c:5545
#7  0x00007f31fb2dde52 in g_main_dispatch (context=0x55b64fee7ed0) at gmain.c:3203
#8  0x00007f31fb2dde52 in g_main_context_dispatch (context=context@entry=0x55b64fee7ed0) at gmain.c:3856
#9  0x00007f31fb2de1d0 in g_main_context_iterate (context=context@entry=0x55b64fee7ed0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3929
#10 0x00007f31fb2de27c in g_main_context_iteration (context=context@entry=0x55b64fee7ed0, may_block=may_block@entry=1) at gmain.c:3990
#11 0x00007f31fb896b9d in g_application_run (application=
    0x55b64ff190e0 [Gjs_Application], argc=1, argv=0x55b64ff1c1f0) at gapplication.c:2381
#12 0x00007f31fc1a0c58 in ffi_call_unix64 () at ../src/x86/unix64.S:76
#13 0x00007f31fc1a06ba in ffi_call (cif=cif@entry=0x55b64ffd4418, fn=<optimized out>, rvalue=<optimized out>, 
    rvalue@entry=0x7ffc90884b00, avalue=avalue@entry=0x7ffc908849d0) at ../src/x86/ffi64.c:525
#14 0x00007f31fdcf8d01 in gjs_invoke_c_function(JSContext*, Function*, JSObject*, unsigned int, jsval*, jsval*, GArgument*) (context=context@entry=0x55b64fe5d480, function=function@entry=0x55b64ffd4400, obj=obj@entry=0x7f31e879a760, js_argc=js_argc@entry=1, js_argv=js_argv@entry=0x55b64fe9dc78, js_rval=js_rval@entry=0x7ffc90884d10, r_value=<optimized out>) at gi/function.cpp:999
#15 0x00007f31fdcfa47f in function_call(JSContext*, unsigned int, jsval*) (context=0x55b64fe5d480, js_argc=1, vp=0x55b64fe9dc68) at gi/function.cpp:1323
#16 0x00007f31fabf52fc in js::CallJSNative(JSContext*, int (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (args=..., native=<optimized out>, cx=0x55b64fe5d480) at /usr/src/debug/mozjs-24.2.0/js/src/jscntxtinlines.h:321
#17 0x00007f31fabf52fc in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (cx=cx@entry=0x55b64fe5d480, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /usr/src/debug/mozjs-24.2.0/js/src/vm/Interpreter.cpp:474
#18 0x00007f31fabf6318 in Interpret(JSContext*, js::RunState&) (cx=cx@entry=0x55b64fe5d480, state=...)
    at /usr/src/debug/mozjs-24.2.0/js/src/vm/Interpreter.cpp:2298
#19 0x00007f31fabfe878 in js::RunScript(JSContext*, js::RunState&) (cx=cx@entry=0x55b64fe5d480, state=...)
    at /usr/src/debug/mozjs-24.2.0/js/src/vm/Interpreter.cpp:438
#20 0x00007f31fabff9fa in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) (result=0x7ffc90885690, evalInFrame=..., type=js::EXECUTE_GLOBAL, thisv=<synthetic pointer>..., scopeChainArg=..., script=..., cx=0x55b64fe5d480)
    at /usr/src/debug/mozjs-24.2.0/js/src/vm/Interpreter.cpp:622
#21 0x00007f31fabff9fa in js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) (cx=cx@entry=0x55b64fe5d480, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0x7ffc90885690)
    at /usr/src/debug/mozjs-24.2.0/js/src/vm/Interpreter.cpp:659
#22 0x00007f31facacbbd in JS::Evaluate(JSContext*, JS::Handle<JSObject*>, JS::CompileOptions, unsigned short const*, unsigned long, JS::Value*) (cx=cx@entry=0x55b64fe5d480, obj=obj@entry=..., options=..., chars=chars@entry=0x55b64fececb0, length=<optimized out>, rval=rval@entry=0x7ffc90885690) at /usr/src/debug/mozjs-24.2.0/js/src/jsapi.cpp:5443
#23 0x00007f31facaccce in JS::Evaluate(JSContext*, JS::Handle<JSObject*>, JS::CompileOptions, char const*, unsigned long, JS::Value*) (cx=cx@entry=0x55b64fe5d480, obj=obj@entry=..., options=..., bytes=bytes@entry=0x55b64fe3a1f7 "imports.package.init({ name: \"gnome-documents\",\n", ' ' <repeats 23 times>, "version: \"3.22.3\",\n", ' ' <repeats 23 times>, "prefix: \"/usr\",\n", ' ' <repeats 23 times>, "libdir: \"/usr/lib64\" });\nimports.package.run(imp"..., length=<optimized out>, rval=rval@entry=0x7ffc90885690) at /usr/src/debug/mozjs-24.2.0/js/src/jsapi.cpp:5473
#24 0x00007f31fdcec0f6 in gjs_eval_with_scope(JSContext*, JSObject*, char const*, gssize, char const*, jsval*) (context=0x55b64fe5d480, object=0x7f31ea236160, 
    object@entry=0x0, script=0x55b64fe3a1f7 "imports.package.init({ name: \"gnome-documents\",\n", ' ' <repeats 23 times>, "version: \"3.22.3\",\n", ' ' <repeats 23 times>, "prefix: \"/usr\",\n", ' ' <repeats 23 times>, "libdir: \"/usr/lib64\" });\nimports.package.run(imp"..., 
    script@entry=0x55b64fe3a1e0 "#!/usr/bin/gjs-console\nimports.package.init({ name: \"gnome-documents\",\n", ' ' <repeats 23 times>, "version: \"3.22.3\",\n", ' ' <repeats 23 times>, "prefix: \"/usr\",\n", ' ' <repeats 23 times>, "libdir: \"/usr/lib64\" });\n"..., script_len=<optimized out>, 
    script_len@entry=235, filename=filename@entry=0x7ffc9088707c "/usr/bin/gnome-documents", retval_p=retval_p@entry=0x7ffc90885760) at gjs/jsapi-util.cpp:1325
#25 0x00007f31fdce4c63 in gjs_context_eval(GjsContext*, char const*, gssize, char const*, int*, GError**) (js_context=0x55b64fe3f000 [GjsContext], script=0x55b64fe3a1e0 "#!/usr/bin/gjs-console\nimports.package.init({ name: \"gnome-documents\",\n", ' ' <repeats 23 times>, "version: \"3.22.3\",\n", ' ' <repeats 23 times>, "prefix: \"/usr\",\n", ' ' <repeats 23 times>, "libdir: \"/usr/lib64\" });\n"..., script_len=235, filename=0x7ffc9088707c "/usr/bin/gnome-documents", exit_status_p=0x7ffc908857ec, error=0x7ffc908857f0) at gjs/context.cpp:645
#26 0x000055b64f30a458 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at gjs/console.cpp:146
(gdb)

Comment 10 Martin Krajnak 2017-04-28 13:55:02 UTC
So what do you think ? should I report this against libreoffice with the same reproducer ? Is there a chance they will fix it ?

Comment 11 Debarshi Ray 2017-05-01 18:34:22 UTC
(In reply to Martin Krajnak from comment #10)
> So what do you think ? should I report this against libreoffice with the
> same reproducer ? Is there a chance they will fix it ?

Yes, sure. It is worth trying. In the meantime I will try to come up with a simple toy program that exhibits this bug.

Comment 12 Caolan McNamara 2017-05-05 15:17:11 UTC
So, I've had a look at this bug and there's a bunch of problems.

The immediate reason the 2nd presentation crashes is because the 2nd LOKWidget thinks it is the only LOKWidget and thinks the presentation is the 1st (and only) document open. But its the 2nd document of two open because the 1st is not closed.

The 1st is not closed because the close is done in the (1st instance) widget finalize, and finalize is not done yet on the previous widget, because GC in javascript I believe.

We could move the document close into the widget destroy rather than finalize and then it won't crash on second document load.

But we'll still crash somewhere else. This is because each widget tries to create a new LibreOffice instance (dlopen and init and teardown) and this currently only works because the finalize *isn't* run. If it is run then the first libreoffice instance torn down trashes the rest of the ones opened in the future.

There's a bunch of statically inited things so creating a new instance even if the previous one is torn down doesn't reinit those variables. I guess if all the dlopens that LibreOffice did were matched properly with dlcloses there's a chance it might do the right thing.

A shared libreoffice instance for all widgets is a possibility but shutting it down is then still a problem. Letting it die atexit causes other problems, not shutting it down at all is also dodgy, and trying to find some way to schedule it e.g. when g_main_loop quits is also difficult as far as I can see.

I'll try a few more things

Comment 13 Caolan McNamara 2017-05-08 16:03 UTC
Created attachment 1277127 [details]
gnome-document patch to shutdown lok promptly

gnome-documents part of this

Comment 14 Caolan McNamara 2017-05-08 16:05 UTC
Created attachment 1277128 [details]
libreoffice part of it

various patches squashed together to enable restart of the LOK main loop with some chance of success

Comment 15 Caolan McNamara 2017-05-08 16:07:02 UTC
with master gnome-documents and libreoffice with the above applied I get no crashes on repeated opening of libreoffice documents from within gnome-documents, and no crash on gnome-documents exit either

https://gerrit.libreoffice.org/#/c/37398/
https://gerrit.libreoffice.org/#/c/37399/

Comment 16 Caolan McNamara 2017-05-11 08:03 UTC
Created attachment 1277773 [details]
backports to rhel-7 of libreoffice side

backports to rhel-7 libreoffice

caolanm->Debarshi: There is one patch necessary to gnome-documents (above) needed to make this work. If you are agreeable to applying that patch to gnome-documents then I can make the libreoffice changes required to make this work.

Comment 17 Debarshi Ray 2017-05-11 09:21:09 UTC
(In reply to Caolan McNamara from comment #13)
> Created attachment 1277127 [details]
> gnome-document patch to shutdown lok promptly
> 
> gnome-documents part of this

Thanks for the patch, Caolan!

(In reply to Caolan McNamara from comment #16)
> Created attachment 1277773 [details]
> backports to rhel-7 of libreoffice side
> 
> backports to rhel-7 libreoffice
> 
> caolanm->Debarshi: There is one patch necessary to gnome-documents (above)
> needed to make this work. If you are agreeable to applying that patch to
> gnome-documents then I can make the libreoffice changes required to make
> this work.

Of course. It is building as we speak. Here is a scratch build:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13177943

Comment 18 Debarshi Ray 2017-05-11 09:22:14 UTC
Built gnome-documents-3.22.2-4.el7:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13177994

Comment 20 Debarshi Ray 2017-05-11 11:47:57 UTC
(In reply to Caolan McNamara from comment #14)
> Created attachment 1277128 [details]
> libreoffice part of it
> 
> various patches squashed together to enable restart of the LOK main loop
> with some chance of success

For what it is worth, you could also use the 'dispose' vfunc to shutdown LOK, but in this case it doesn't really matter. 'dispose' is a GObject virtual function, while 'destroy' is from GtkWidget.

Comment 22 Martin Krajnak 2017-05-23 10:17:10 UTC
I have updated both libreoffice and gnome-documents to following versions:

libreofficekit-5.0.6.2-10.el7.x86_64
libreoffice-5.0.6.2-10.el7.x86_64
gnome-documents-3.22.2-4.el7.x86_64

The segfault is gone but another problem has appeared with the following reproducer:

1.Open documents
2.Open a presentation or any other document in libreoffice/msoffice format
3.After the document renders, go back to documents overview
4.Again open the same or any other document in libreoffice/msoffice format

Result:
Application is stuck in the document overview, document is not rendered, I am not able to perform any action except killing it from terminal. I can reproduce this on two machines.

Comment 23 Caolan McNamara 2017-05-25 15:33:57 UTC
ok, I know what this is now and its a simple missing oneliner in libreoffice, we set a quit flag at the first close and failed to unset it on the second open, I'll try and sort that out in a >= libreoffice-5.0.6.2-11.el7

Comment 24 Martin Krajnak 2017-06-14 11:52:34 UTC
I updated the libreofficekit-5.0.6.2-12.el7.x86_64, the freeze from comment 22 is gone but when I am randomly opening libre office documents I think that I am getting the similar segmentation fault (compared to full stack trace provided by Debarshi). I cannot exactly reproduce the crash but it always occurs between 3rd to 10th attempt for opening documents.

gnome-documents-3.22.2-5.el7.x86_64

program received signal SIGSEGV, Segmentation fault.
handleTimeout (pData=<optimized out>)
    at /usr/src/debug/libreoffice-5.0.6.2/libreofficekit/source/gtk/lokdocview.cxx:700
700	    if (priv->m_bEdit)
(gdb) backtrace
#0  handleTimeout (pData=<optimized out>)
    at /usr/src/debug/libreoffice-5.0.6.2/libreofficekit/source/gtk/lokdocview.cxx:700
#1  0x00007fd60e3d8eed in g_timeout_dispatch () from /lib64/libglib-2.0.so.0
#2  0x00007fd60e3d84c9 in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#3  0x00007fd60e3d8818 in g_main_context_iterate.isra.21 ()
   from /lib64/libglib-2.0.so.0
#4  0x00007fd60e3d88cc in g_main_context_iteration ()
   from /lib64/libglib-2.0.so.0
#5  0x00007fd60e9907c5 in g_application_run () from /lib64/libgio-2.0.so.0
#6  0x00007fd60f298dcc in ffi_call_unix64 () from /lib64/libffi.so.6
#7  0x00007fd60f2986f5 in ffi_call () from /lib64/libffi.so.6
#8  0x00007fd610dae65e in gjs_invoke_c_function (context=context@entry=
    0x1d56400, function=function@entry=0x1e8e520, 
    obj=obj@entry=0x7fd5fc39e760, js_argc=js_argc@entry=1, 
    js_argv=js_argv@entry=0x1d96778, js_rval=js_rval@entry=0x7ffc6392f9d0, 
    r_value=r_value@entry=0x0) at gi/function.cpp:999
#9  0x00007fd610dafb21 in function_call (context=0x1d56400, js_argc=1, 
    vp=0x1d96768) at gi/function.cpp:1323
#10 0x00007fd60dcbc8f2 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () from /lib64/libmozjs-24.so
#11 0x00007fd60dcc0731 in Interpret(JSContext*, js::RunState&) ()
---Type <return> to continue, or q <return> to quit---
   from /lib64/libmozjs-24.so
#12 0x00007fd60dcca048 in js::RunScript(JSContext*, js::RunState&) ()
   from /lib64/libmozjs-24.so
#13 0x00007fd60dcca274 in js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) () from /lib64/libmozjs-24.so
#14 0x00007fd60dd7743b in JS::Evaluate(JSContext*, JS::Handle<JSObject*>, JS::CompileOptions, unsigned short const*, unsigned long, JS::Value*) ()
   from /lib64/libmozjs-24.so
#15 0x00007fd60dd7759e in JS::Evaluate(JSContext*, JS::Handle<JSObject*>, JS::CompileOptions, char const*, unsigned long, JS::Value*) ()
   from /lib64/libmozjs-24.so
#16 0x00007fd610da1725 in gjs_eval_with_scope (context=0x1d56400, 
    object=0x7fd5fde36160, 
    script=0x1d33057 "imports.package.init({ name: \"gnome-documents\",\n", ' ' <repeats 23 times>, "version: \"3.22.2\",\n", ' ' <repeats 23 times>, "prefix: \"/usr\",\n", ' ' <repeats 23 times>, "libdir: \"/usr/lib64\" });\nimports.package.run(imp"..., script_len=212, 
    filename=0x7ffc6393234c "/usr/bin/gnome-documents", 
    retval_p=0x7ffc639304d0) at gjs/jsapi-util.cpp:1325
#17 0x00007fd610d9a373 in gjs_context_eval (js_context=0x1d38000, 
    script=0x1d33040 "#!/usr/bin/gjs-console\nimports.package.init({ name: \"gnome-documents\",\n", ' ' <repeats 23 times>, "version: \"3.22.2\",\n", ' ' <repeats 23 times>, "prefix: \"/usr\",\n", ' ' <repeats 23 times>, "libdir: \"/usr/lib---Type <return> to continue, or q <return> to quit---
64\" });\n"..., script_len=235, 
    filename=0x7ffc6393234c "/usr/bin/gnome-documents", 
    exit_status_p=0x7ffc6393055c, error=0x7ffc63930560) at gjs/context.cpp:645
#18 0x00000000004012df in main (argc=1, argv=0x7ffc63930690)
    at gjs/console.cpp:147

Comment 25 Martin Krajnak 2017-06-14 13:12:43 UTC
this might also help, before the crash appears there is a warning about unclassed pointer in stderr.

[test@hp-moonshot-03-c24 yum.repos.d]$ gnome-documents
error: Could not find thumbnail in zip file

(org.gnome.Documents:4487): GnomeDesktop-WARNING **: Error creating thumbnail for file:///home/test/Documents/TestPasswordProtectedODT.odt: Unrecognized image file format

(org.gnome.Documents:4487): GnomeDesktop-WARNING **: Error creating thumbnail for file:///home/test/Documents/TestPasswordProtectedPDF.pdf: Unrecognized image file format
error: Could not find thumbnail in zip file

(org.gnome.Documents:4487): GnomeDesktop-WARNING **: Error creating thumbnail for file:///home/test/Documents/demo.docx: Unrecognized image file format
error: Could not find thumbnail in zip file

(org.gnome.Documents:4487): GnomeDesktop-WARNING **: Error creating thumbnail for file:///home/test/Documents/cellstyle.xlsx: Unrecognized image file format

(org.gnome.Documents:4487): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'LOKDocView'

(org.gnome.Documents:4487): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'LOKDocView'

(org.gnome.Documents:4487): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'LOKDocView'

(org.gnome.Documents:4487): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'LOKDocView'

(org.gnome.Documents:4487): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'LOKDocView'

(org.gnome.Documents:4487): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'LOKDocView'

(org.gnome.Documents:4487): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'LOKDocView'

(org.gnome.Documents:4487): GLib-GObject-WARNING **: invalid cast from 'GtkSeparator' to 'LOKDocView'
Segmentation fault (core dumped)

Comment 26 Caolan McNamara 2017-06-15 08:59:24 UTC
The backtrace shows its crashing in handleTimeout. I believe this happens if one opens and document and closes it before the timer was fired, so when it does fire it uses a deleted view. So has to close the document in less than 600ms from opening it. I have a patch to drop the timer if it hasn't fired when closing the document which works for me as far as I can see to fix this latest crash

Comment 28 Caolan McNamara 2017-06-16 07:57:51 UTC
libreoffice-5.0.6.2-13.el7 now available for re-testing

Comment 29 Martin Krajnak 2017-06-16 10:15:32 UTC
Good work, I ran the automated tests and also tested manually and wasn't able to reproduce anymore. Moving to verified as it works with

libreoffice-5.0.6.2-13.el7
gnome-documents-3.22.2-5.el7.x86_64

Comment 30 Mike Gorse 2017-07-26 20:21:45 UTC
I just noticed that the gnome-documents patch from comment 13 isn't in master. Should it be pushed there?

Comment 31 Debarshi Ray 2017-07-27 16:02:16 UTC
(In reply to Mike Gorse from comment #30)
> I just noticed that the gnome-documents patch from comment 13 isn't in
> master. Should it be pushed there?

It is not 100% clear that the patch is actually needed, but it is not harmful either. See the upstream bug:
https://bugzilla.gnome.org/show_bug.cgi?id=782508

I need to dig into object lifecycles in gjs, which I will do once the dust settles.

Comment 32 errata-xmlrpc 2017-08-01 10:01:37 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2312


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