This is hard to track down as libreoffice-debuginfo erroneously doesn't contain debug info, see bug 1545629.  All we know from attachment 1395931 [details] is that GtkSalFrame::CallCallbackExc in libvclplug_gtk3lo.so failed by raising a signal (and LO's signal handling then continued to ultimately call abort(3)).

Agreed, I also want to add that I've been trying very hard to reproduce the crash manually and I haven't been able to crash it manually at all, so I am not sure if there is any chance that this can affect users.

The hope would be that with bug 1545629 fixed, Martin's automated tests will eventually reproduce the occasional crash, and the resulting more precise backtrace data might give a clue what's going wrong.

Please retry with proper debuginfo in libreoffice-debuginfo-5.3.6.1-10.el7.ppc64le.rpm, and lets hope for a more enlightening backtrace.

Created attachment 1397162 [details]
core_backtrace

libreoffice-5.3.6.1-10.el7.ppc64le
libreoffice-debuginfo-5.3.6.1-10.el7.ppc64le

This time one occurrence was with LO Writer

(1)  A core_backtrace like in attachment 1397162 [details] isn't too helpful, it doesn't benefit from the debuginfo.  What would be needed is a gdb-processed backtrace (as can be obtained through abrt).

(2)  The only information about the stack frame causing the deadly signal in attachment 1397162 [details] is

>               , {   "address": 70367233901688
>                 ,   "build_id": "fca3378483f69f305c6bb3571706b7f91224b414"
>                 ,   "build_id_offset": 1144
>                 } ]

which doesn't look promising.  (And this crash looks rather different from the one in comment 0.  Either the root cause is some random memory corruption, or these crashes are likely unrelated.)

(3)  Is this a regression?  Did you run the same tests successfully in the past/on older RHEL?

Here is everything from abrt that I was able to retrieve from that crash.

https://drive.google.com/file/d/17kC3bmUsTx3jk6dApjGiGUYqL-VaJ06V/view?usp=sharing
https://drive.google.com/file/d/10pYbn3G7tN6PCpGy8k-r9HbSyVMf5lMa/view?usp=sharing

(Files has are bigger than 20 MB so they cannot be uploaded as attachment)

As I mentioned on IRC, I can't recall this particular crash from previous RHEL releases. I should have reported the crash sooner but our automation was partially blocked on ppc64le, thus I discovered only last week.

The relevant part of the backtrace file in <https://drive.google.com/file/d/17kC3bmUsTx3jk6dApjGiGUYqL-VaJ06V/view>:

> #12 <signal handler called>
> No locals.
> #13 0x00003fff00000004 in ?? ()
> No symbol table info available.
> #14 0x00003fff7d3674b8 in CallCallback (pEvent=0x3fffead4ce08, nEvent=LongPress, this=0x3fffead4d130) at /usr/src/debug/libreoffice-5.3.6.1/vcl/inc/salframe.hxx:276
> No locals.
> #15 GtkSalFrame::CallCallbackExc (this=0x3fffead4d130, nEvent=LongPress, pEvent=0x3fffead4ce08) at /usr/src/debug/libreoffice-5.3.6.1/vcl/unx/gtk3/gtk3gtkframe.cxx:4384
>         nRet = 0
> #16 0x00003fff7d367790 in GtkSalFrame::gestureLongPress (gesture=0x1002bbf4ec0, frame=0x3fffead4d130) at /usr/src/debug/libreoffice-5.3.6.1/vcl/unx/gtk3/gtk3gtkframe.cxx:2854
>         aEvent = {mnX = 512, mnY = 288}
>         x = 512
>         y = 288
>         sequence = 0x0
>         pThis = 0x3fffead4d130
> #17 0x00003fff89257254 in ffi_call_LINUX64 () at ../src/powerpc/linux64.S:133
> No locals.
> #18 0x00003fff89255f50 in ffi_call (cif=0x3fffead4d130, fn=<optimized out>, rvalue=0x3fffead4d0b0, avalue=0x3fffead4d050) at ../src/powerpc/ffi.c:100
>         smst_buffer = {1100253445216, 70368389025872, 70366540036352, 70366756015428, 70366763111168, 1100245071216, 1100245895392, 70368389025936}
>         ecif = {cif = 0x3fffead4d130, rvalue = 0x3fffead4d0b0, avalue = 0x3fffead4d050}
> #19 0x00003fff8d894ce0 in g_cclosure_marshal_generic_va (closure=0x1002c1841c0, return_value=0x0, instance=0x1002bbf4ec0, args_list=<optimized out>, marshal_data=0x0, n_params=<optimized out>, param_types=0x1002bc408e0) at gclosure.c:1604
>         rtype = 0x3fff89257760 <ffi_type_void>
>         rvalue = 0x3fffead4d0b0
>         n_args = 4
>         atypes = 0x3fffead4d080
>         args = 0x3fffead4d050
>         storage = 0x3fffead4d030
>         i = <optimized out>
>         cif = {abi = FFI_DEFAULT_ABI, nargs = 4, arg_types = 0x3fffead4d080, rtype = 0x3fff89257760 <ffi_type_void>, bytes = 240, flags = 33554434, nfixedargs = 4}
>         cc = 0x1002c1841c0
>         enum_tmpval = <optimized out>
>         tmpval_used = 0
>         args_copy = 0x3fffead4d478 ""
> #20 0x00003fff8d893d6c in _g_closure_invoke_va (closure=0x1002c1841c0, return_value=0x0, instance=0x1002bbf4ec0, args=0x3fffead4d468 "", n_params=<optimized out>, param_types=0x1002bc408e0) at gclosure.c:867
>         marshal = 0x3fff8d8948d0 <g_cclosure_marshal_generic_va>
>         marshal_data = 0x0
>         in_marshal = 0
>         real_closure = 0x1002c1841a0
>         __FUNCTION__ = "_g_closure_invoke_va"
> #21 0x00003fff8d8b82a0 in g_signal_emit_valist (instance=0x1002bbf4ec0, signal_id=<optimized out>, detail=<optimized out>, var_args=0x3fffead4d468 "") at gsignal.c:3300
>         return_accu = 0x0
>         accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
>         accumulator = 0x0
>         emission = {next = 0x0, instance = 0x1002bbf4ec0, ihint = {signal_id = 233, detail = 0, run_type = G_SIGNAL_RUN_FIRST}, state = EMISSION_RUN, chain_type = 1100245531216}
>         instance_type = 1100245531216
>         emission_return = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
>         rtype = 4
>         static_scope = 0
>         fastpath_handler = <optimized out>
>         closure = 0x1002c1841c0
>         run_type = <optimized out>
>         l = <optimized out>
>         fastpath = <optimized out>
>         instance_and_params = <optimized out>
>         signal_return_type = <optimized out>
>         param_values = <optimized out>
>         node = 0x1002bc8ea00
>         i = <optimized out>
>         n_params = <optimized out>
>         __FUNCTION__ = "g_signal_emit_valist"
> #22 0x00003fff8d8b8e60 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3447
>         var_args = <optimized out>
> #23 0x00003fff7ccaa5a0 in _gtk_gesture_long_press_timeout (user_data=0x1002bbf4ec0) at gtkgesturelongpress.c:108
>         gesture = 0x1002bbf4ec0
>         priv = 0x1002bbf4e20
>         sequence = <optimized out>
>         x = 512
>         y = 288
> #24 0x00003fff7c8ec8e8 in gdk_threads_dispatch (data=0x1002bdc1a60) at gdk.c:743
>         dispatch = 0x1002bdc1a60
>         ret = 0
> #25 0x00003fff8d7754c8 in g_timeout_dispatch (source=0x1002cffd420, callback=<optimized out>, user_data=<optimized out>) at gmain.c:4631
>         timeout_source = 0x10028554d90
>         again = <optimized out>
> #26 0x00003fff8d774230 in g_main_dispatch (context=0x10028552d30) at gmain.c:3146
>         dispatch = 0x3fff8d775480 <g_timeout_dispatch>
>         prev_source = 0x0
>         was_in_call = 0
>         user_data = 0x1002bdc1a60
>         callback = 0x3fff7c8ec870 <gdk_threads_dispatch>
>         cb_funcs = 0x3fff8d8709e0 <g_source_callback_funcs>
>         cb_data = 0x1002c31f9d0
>         need_destroy = <optimized out>
>         source = 0x1002cffd420
>         current = 0x10028554d90
>         i = 0
> #27 g_main_context_dispatch (context=0x10028552d30) at gmain.c:3811
> No locals.
> #28 0x00003fff8d7746b8 in g_main_context_iterate (context=0x10028552d30, block=1, dispatch=1, self=<optimized out>) at gmain.c:3884
>         max_priority = 2147483647
>         timeout = 93
>         some_ready = 1
>         nfds = <optimized out>
>         allocated_nfds = <optimized out>
>         fds = 0x1002be09c20
> #29 0x00003fff8d7747ec in g_main_context_iteration (context=0x10028552d30, may_block=<optimized out>) at gmain.c:3945
>         retval = <optimized out>
> #30 0x00003fff7d322250 in GtkData::Yield (this=0x100285cc5e0, bWait=<optimized out>, bHandleAllCurrentEvents=<optimized out>) at /usr/src/debug/libreoffice-5.3.6.1/vcl/unx/gtk3/gtk3gtkdata.cxx:476
> No locals.
> #31 0x00003fff7d32423c in GtkInstance::DoYield (this=<optimized out>, bWait=<optimized out>, bHandleAllCurrentEvents=<optimized out>, nReleased=<optimized out>) at /usr/src/debug/libreoffice-5.3.6.1/vcl/unx/gtk/gtkinst.cxx:427
> No locals.
> #32 0x00003fff89ba9944 in ImplYield (nReleased=0, i_bAllEvents=false, i_bWait=<optimized out>) at /usr/src/debug/libreoffice-5.3.6.1/vcl/source/app/svapp.cxx:507
>         pSVData = 0x3fff89eb4b88 <rtl::Static<ImplSVData, (anonymous namespace)::private_aImplSVData>::get()::instance>
>         bHasActiveIdles = false
>         eResult = <optimized out>
> #33 Application::Yield () at /usr/src/debug/libreoffice-5.3.6.1/vcl/source/app/svapp.cxx:552
> No locals.
> #34 0x00003fff89bacee4 in Application::Execute () at /usr/src/debug/libreoffice-5.3.6.1/vcl/source/app/svapp.cxx:469
>         pSVData = 0x3fff89eb4b88 <rtl::Static<ImplSVData, (anonymous namespace)::private_aImplSVData>::get()::instance>
> #35 0x00003fff8df8e3a4 in DoExecute () at /usr/src/debug/libreoffice-5.3.6.1/desktop/source/app/app.cxx:1358
> No locals.
> #36 desktop::Desktop::Main (this=0x3fffead4db58) at /usr/src/debug/libreoffice-5.3.6.1/desktop/source/app/app.cxx:1685
>         layer2 = {m_aEnvTypeName = "gcc3", m_xPreviousContext = uno::Reference to (desktop::DesktopContext *) 0x3fff7a45f078}
>         bTerminateRequested = false
>         xRestartManager = uno::Reference to (comphelper::OOfficeRestartManager *) 0x3fff7a538f10
>         layer = {m_aEnvTypeName = "gcc3", m_xPreviousContext = uno::Reference to (DesktopEnvironmentContext *) 0x3fff7d590030}
>         xContext = uno::Reference to (cppu::ComponentContext *) 0x3fff7d4937d8
>         aOptions = {<utl::detail::Options> = {<utl::ConfigurationBroadcaster> = {_vptr.ConfigurationBroadcaster = 0x3fff8abcf6e0 <vtable for SvtAccessibilityOptions+16>, mpList = 0x0, m_nBroadcastBlocked = 0, m_nBlockedHint = 0}, <utl::ConfigurationListener> = {_vptr.ConfigurationListener = 0x3fff8abcf718 <vtable for SvtAccessibilityOptions+72>}, <No data fields>}, <SfxListener> = {_vptr.SfxListener = 0x3fff8abcf740 <vtable for SvtAccessibilityOptions+112>, mpImpl = std::unique_ptr<SfxListener::Impl> containing 0x1002c0a9150}, static sm_pSingleImplConfig = 0x1002c0b0550, static sm_nAccessibilityRefCount = 8}
>         aUnknown = ""
>         inst_fin = <optimized out>
>         xDesktop = uno::Reference to (framework::Desktop *) 0x3fff7a3f6e68
>         aAppearanceCfg = {<utl::ConfigItem> = {<utl::ConfigurationBroadcaster> = {_vptr.ConfigurationBroadcaster = 0x3fff8abcf798 <vtable for SvtTabAppearanceCfg+16>, mpList = 0x0, m_nBroadcastBlocked = 0, m_nBlockedHint = 0}, sSubTree = "Office.Common/View", m_xHierarchyAccess = uno::Reference to (configmgr::RootAccess *) 0x3fff7d47d840, xChangeLstnr = empty uno::Reference, m_nMode = DelayedUpdate, m_bIsModified = false, m_bEnableInternalNotification = false, m_nInValueChange = 0}, nDragMode = SystemDep, nSnapMode = NONE, nMiddleMouse = PasteSelection, nAAMinPixelHeight = 8, bMenuMouseFollow = true, bFontAntialiasing = true, static bInitialized = true}
> #37 0x00003fff89bb34a0 in ImplSVMain () at /usr/src/debug/libreoffice-5.3.6.1/vcl/source/app/svmain.cxx:186
>         pSVData = 0x3fff89eb4b88 <rtl::Static<ImplSVData, (anonymous namespace)::private_aImplSVData>::get()::instance>
>         nReturn = 1
>         bInit = true
> #38 0x00003fff89bb3614 in SVMain () at /usr/src/debug/libreoffice-5.3.6.1/vcl/source/app/svmain.cxx:224
>         nRet = 0
> #39 0x00003fff8dfc2798 in soffice_main () at /usr/src/debug/libreoffice-5.3.6.1/desktop/source/app/sofficemain.cxx:166
>         aDesktop = {<Application> = {_vptr.Application = 0x3fff8e04cfa0 <vtable for desktop::Desktop+16>}, m_rSplashScreen = empty uno::Reference, m_bCleanedExtensionCache = false, m_bServicesRegistered = true, m_aBootstrapError = desktop::Desktop::BE_OK, m_aBootstrapErrorMessage = "", m_aBootstrapStatus = desktop::Desktop::BS_OK, m_xLockfile = std::unique_ptr<desktop::Lockfile> containing 0x0, m_firstRunTimer = {<Scheduler> = {_vptr.Scheduler = 0x3fff89ea19c0 <vtable for Timer+16>, mpSchedulerData = 0x1002bf271a0, mpDebugName = 0x0, mePriority = HIGHEST, mbActive = true, static ImmediateTimeoutMs = 1, static InfiniteTimeoutMs = 86400000}, maTimeoutHdl = {function_ = 0x3fff8df81e20 <desktop::Desktop::LinkStubAsyncInitFirstRun(void*, Timer*)>, instance_ = 0x3fffead4db58}, mnTimeout = 3000, mbAuto = false}, static pResMgr = 0x1002c054ae0}
>         rCmdLineArgs = <optimized out>
> #40 0x0000000010000740 in sal_main () at /usr/src/debug/libreoffice-5.3.6.1/desktop/source/app/main.c:48
>         ret = <optimized out>
> #41 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/libreoffice-5.3.6.1/desktop/source/app/main.c:47
> No locals.

So Stephan do you still think this is fixable in 7.5? Or should we rather postpone to 7.6?

Better postpone to 7.6 (and maybe this even happens to already be fixed in a later version of LO).  That backtrace doesn't seem to ring a bell for anybody, and without a reliable reproducer it's hard to investigate further.  And given this is only reported with the test tooling, lets hope it will not affect actual end-user use of LO on ppc64le.

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

[wrongly pressed devel_nack]

Valid in 7.6, reproducer is still not clear, just documenting its appearence

http://lab-02.rhts.eng.bos.redhat.com/beaker/logs/results/362842+/362842285/report_libreoffice_Test34_impress_duplicate_slide.html

(In reply to Martin Krajnak from comment #14)
> Valid in 7.6, reproducer is still not clear, just documenting its appearence
> 
> http://lab-02.rhts.eng.bos.redhat.com/beaker/logs/results/362842+/362842285/
> report_libreoffice_Test34_impress_duplicate_slide.html

That link is 404 by now.  Is the crash backtrace still the same as in comment 9?

Sorry for inconvenience, I am currently re-running the job. The circumstances in which bug is appearing are the same as they were in 7.5 which is quite understandable since there were no mayor update for libreoffice.

Just to remind them:
- the crash is only under impress
- the crash is only under ppc64le
- the crash is random 
- I've never managed to reproduce the crash manually, only via automated test, so I think it'll be quite hard for user to hit the issue.


I'try to provide the traceback later today or tomorrow.

Ok finally managed to get the abrt folder

https://drive.google.com/open?id=1Rb7rzniT2QSyiTg1Lx3TBuwxJ1c6Ud37

from my perspective it is the same crash

Yes, that's still effectively the same backtrace as in comment 9 (with the SalFrame::CallCallback call through this->m_pProc landing at 0x0000004100000004 instead of 0x00003fff00000004).

I see two plausible scenarios how this could fail:  Either, the SalFrame pointer (transported as a gpointer through the GTK signalling functionality to LO's GtkSalFrame::gestureLongPress) points at an already destroyed SalFrame, and its m_pProc member has already been overwritten; what makes this less likely is that the issue is reported to only happen on ppc64le.  Or there is a bug in the (partially ppc64le-specific) GTK signalling functionality (stack frames 22 g_signal_emit through 17 ffi_call_LINUX64 in comment 9) that only hits sporadically and causes wrong payload data to come out at the end.  For either scenario, I would have no idea how to track it down without a decently reliable reproducer.

What is the nature of those automated tests that exhibit this issue?  From the backtraces, this doesn't appear to use LO's remote UNO to programatically do things?  Is every test using a fresh LO process, or do multiple tests reuse a single LO process?

Created attachment 1470284 [details]
about dialog test

Those tests are our internal tests developed for RHEL-7, we are using the accessibility features (atspi) that are available in gtk applications. We are able to simulate keyboard and mouse actions which allow us to script the test scenarios so we can test more applications more often in our CI.

I studied for a while upstream tests that are using the UNO interface and UNO library inspired by 
https://mmohrhard.wordpress.com/2016/09/07/ui-testing-in-libreoffice/
but they are not as suitable for us since we are always quite behind the upstream and we have already spent some time developing those.

Yes, every single test is using a fresh LO process, furthermore the whole gnome-session is terminated after every test and a new one is created before every single test.

In the example I posted the about_dialog test, all 4 scenarios are using a new LO process. As you can see by clicking on stderr in failed scenario the crash is there. Even today I've been trying to reproduce the crash on remote machine for some time but I wasn't successful.

<https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=17347745> is a (ppc64le-only) scratch build with the body of GtkSalFrame::gestureLongPress #if'ed out for ppc64le (I hope I got the #if condition right).  Caolan claims that that should not have negative impact on functionality.  Lets see if that would make the spurious test crash go away for good, or whether it will start to show up somewhere else (i.e., in code that would only be executed after the current crash location).

Thanks for scratch build, I started the job with custom rpms, I will report as soon as I receive results.

The first impression is that it went away, I re-run two more to doublecheck that.

Damn, I thought it is gone but I went more carefully through test reports one by one and I found 2 crashes but they must somehow happened after test passed, so the result is green but somehow in stderr I found it crashed, now it crashed twice with writer. 

I am looking now that the packages from scratch build are gone. and the build are also gone so I cannot provide the full abrt log, can you please schedule another scratch build or do you think we hit the same crash and it is meaningless to try something more ?

Fatal exception: Signal 6
Stack:
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x4c184)[0x3fff8059c184]
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x4c394)[0x3fff8059c394]
[0x3fff805e0478]
/lib64/libc.so.6(abort+0x2b4)[0x3fff80281f94]
/usr/lib64/libreoffice/program/libvcllo.so(+0x6be74c)[0x3fff7c13e74c]
/usr/lib64/libreoffice/program/libvcllo.so(_ZN11Application5AbortERKN3rtl8OUStringE+0xdc)[0x3fff7c08905c]
/usr/lib64/libreoffice/program/libsofficeapp.so(+0x246fc)[0x3fff804746fc]
/usr/lib64/libreoffice/program/libvcllo.so(+0x611658)[0x3fff7c091658]
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x17d28)[0x3fff80567d28]
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x4c350)[0x3fff8059c350]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0x84fb80)[0x3fff4de1fb80]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(JVM_handle_linux_signal+0x254)[0x3fff4de27284]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0x843dc8)[0x3fff4de13dc8]
[0x3fff805e0478]
/usr/lib64/libreoffice/program/../program/libswlo.so(+0x775404)[0x3fff4f445404]
/usr/lib64/libreoffice/program/../program/libswlo.so(+0x778b98)[0x3fff4f448b98]
/usr/lib64/libreoffice/program/../program/libswlo.so(_ZN11SwViewShell10LayoutIdleEv+0x104)[0x3fff4f86e964]
/usr/lib64/libreoffice/program/../program/libswlo.so(+0x5494a8)[0x3fff4f2194a8]
/usr/lib64/libreoffice/program/libvcllo.so(_ZN4Idle6InvokeEv+0x38)[0x3fff7c073768]
/usr/lib64/libreoffice/program/libvcllo.so(+0x5f4d7c)[0x3fff7c074d7c]
/usr/lib64/libreoffice/program/libvcllo.so(_ZN9Scheduler21ProcessTaskSchedulingEb+0x38)[0x3fff7c075138]
/usr/lib64/libreoffice/program/libvcllo.so(_ZN11Application5YieldEv+0xa4)[0x3fff7c089964]
/usr/lib64/libreoffice/program/libvcllo.so(_ZN11Application7ExecuteEv+0x64)[0x3fff7c08cee4]
/usr/lib64/libreoffice/program/libsofficeapp.so(+0x2e41c)[0x3fff8047e41c]
/usr/lib64/libreoffice/program/libvcllo.so(+0x6134a0)[0x3fff7c0934a0]
/usr/lib64/libreoffice/program/libvcllo.so(_Z6SVMainv+0x34)[0x3fff7c093614]
/usr/lib64/libreoffice/program/libsofficeapp.so(soffice_main+0xc8)[0x3fff804b27f8]
/usr/lib64/libreoffice/program/soffice.bin[0x10000740]
/lib64/libc.so.6(+0x25100)[0x3fff80265100]
/lib64/libc.so.6(__libc_start_main+0xc4)[0x3fff802652f4]

(In reply to Martin Krajnak from comment #24)
> I am looking now that the packages from scratch build are gone. and the
> build are also gone so I cannot provide the full abrt log, can you please
> schedule another scratch build or do you think we hit the same crash and it
> is meaningless to try something more ?

started new scratch build at <https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=17467080>

Hello, thanks again for the scratch build. Sorry that it took me so long but I made some progress (at least, I think). The crash occurs less and less, but I finally managed to isolate reproducer which is quite strange:

So on ppc64le
1. Open writer
2. Navigate to Help -> About
3. Open terminal and execute killall soffice.bin
Result:
[test@ibm-p8-02-lp6 ~]$ oowriter


Fatal exception: Signal 6
Stack:
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x4c184)[0x3fff9c85c184]
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x4c394)[0x3fff9c85c394]
[0x3fff9c8a0478]
/lib64/libc.so.6(abort+0x2b4)[0x3fff9c541f94]
/usr/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x9663c)[0x3fff9b55663c]
/usr/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x9a0d4)[0x3fff9b55a0d4]
/usr/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x9a3f8)[0x3fff9b55a3f8]
/usr/lib64/libreoffice/program/libsofficeapp.so(+0x23868)[0x3fff9c733868]
/usr/lib64/libreoffice/program/libsofficeapp.so(+0x247a4)[0x3fff9c7347a4]
/usr/lib64/libreoffice/program/libvcllo.so(+0x611658)[0x3fff98351658]
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x17d28)[0x3fff9c827d28]
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x4c350)[0x3fff9c85c350]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0x84fb80)[0x3fff6a1efb80]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(JVM_handle_linux_signal+0x254)[0x3fff6a1f7284]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0x843dc8)[0x3fff6a1e3dc8]
[0x3fff9c8a0478]
/usr/lib64/libreoffice/program/libvcllo.so(+0x6109c4)[0x3fff983509c4]
/lib64/libc.so.6(__cxa_finalize+0x10c)[0x3fff9c544ddc]
/usr/lib64/libreoffice/program/libvcllo.so(+0x24a200)[0x3fff97f8a200]
/lib64/ld64.so.2(+0x17be8)[0x3fff9c8d7be8]
/lib64/libc.so.6(+0x44894)[0x3fff9c544894]
/lib64/libc.so.6(exit+0x24)[0x3fff9c5448e4]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0x597a14)[0x3fff69f37a14]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0xa45788)[0x3fff6a3e5788]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0xa45188)[0x3fff6a3e5188]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0xa42d88)[0x3fff6a3e2d88]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0xa4346c)[0x3fff6a3e346c]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0xa43958)[0x3fff6a3e3958]
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.ppc64le/jre/lib/ppc64le/server/libjvm.so(+0x846150)[0x3fff6a1e6150]
/lib64/libpthread.so.0(+0x8b94)[0x3fff9c4c8b94]
/lib64/libc.so.6(clone+0xe4)[0x3fff9c6285f4]

abrt report:
https://drive.google.com/file/d/17kC3bmUsTx3jk6dApjGiGUYqL-VaJ06V/view?usp=sharing

I believe it is the same one, but now I am not even sure if it is a bug since I am basically crashing it manually with that command.

(In reply to Martin Krajnak from comment #26)
> So on ppc64le
> 1. Open writer
> 2. Navigate to Help -> About
> 3. Open terminal and execute killall soffice.bin

That is a meaningless test.  LO is not supposed to behave in any well-defined way upon receiving SIGTERM; terminating with SIGABRT should be considered an "acceptable" outcome.  (The glibc-produced backtrace you quote in comment 26 suggests that the in-process JVM calls exit; the abrt.zip's backtrace is broken in that it doesn't include a backtrace for the crashed thread, the core_backtrace for the crashing thread looks like it matches the top of the  quoted glibc-produced backtrace alright.)

I can only agree, the test itself should verify that the About dialog is shown, the killall command is issued only as the cleanup after finish of the test so a new test can have a fresh instance.

Before the scratch build the tests were crashing a lot more and the crash was happening in the middle of tests or even after start of application (See attachment 1470284 [details]), so I think we can make a proper build and we can consider it fixed, what do you think ?

Fine with me.  I can include that ppc64le-only patch of making GtkSalFrame::gestureLongPress a nop.

no crashing in libreoffice-5.3.6.1-17.el7

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/RHSA-2018:3054