Created attachment 118446 [details] backtrace Steps: 1) Open libreoffice 2) Tools > Macros > Organize Macros > Javascript 3) Crash Regression as this doesnt happen in 5.0 daily. Version: 5.1.0.0.alpha1+ Build ID: cf9fbdb379e2935677a73ced513d7faf855c299c TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-09-05_00:34:47 Locale: en-US (en_US.UTF-8)
No crash for me with Version: 5.1.0.0.alpha1+ Build ID: d417059dae303685de7aa0f4b1c192ffcf5304d5 Ubuntu_15.04_x86-64 Locale : fr-FR (fr_FR.UTF-8) built at home with GCC 5.1 Best regards. JBF
On pc Debian x86-64 with master sources updated 2 days ago, I don't reproduce this. I tried with SAL_USE_VCLPLUGIN=gtk3 then gtk and finally gen. I couldn't test with kde since I don't build with this option. Perhaps due to some accesbility option enabled?
(In reply to Yousuf (Jay) Philips from comment #0) > Created attachment 118446 [details] > backtrace Useless unfortunately, it has no stack. > Version: 5.1.0.0.alpha1+ > Build ID: cf9fbdb379e2935677a73ced513d7faf855c299c > TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: > 2015-09-05_00:34:47 > Locale: en-US (en_US.UTF-8) Can't reproduce with the same build under Fedora 22 (64-bit).
Created attachment 118461 [details] backtrace (In reply to Julien Nabet from comment #2) > Perhaps due to some accesbility option enabled? I do have accessibility enabled, but dont use it. (In reply to Maxim Monastirsky from comment #3) > Useless unfortunately, it has no stack. Hopefully this debug build backtrace will be useful. Version: 5.1.0.0.alpha1+ Build ID: b2363e98af7b0281279617e43b8fec5b898b9120 TinderBox: Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2015-08-25_23:42:26 Locale: en-US (en_US.UTF-8)
this part: Program received signal SIGSEGV, Segmentation fault. 0x00007fffa9f8bb4d in ?? () #0 0x00007fffa9f8bb4d in ?? () #1 0x00007fffa9f2e310 in ?? () #2 0x0000000000000000 in ?? () makes me think about something Java related. Indeed, when I run gdb to retrieve a bt for Base, I must run continue command 1 or 2 times to have the "real" bt. Just a guess of course since I don't see the real bt here just some threads. Yousuf: just to be sure, do you use brand new profile?
I reproduce with LO 5.1.0.0.alpha1+ Build ID: d417059dae303685de7aa0f4b1c192ffcf5304d5 TinderBox: Win-x86@39, Branch:master, Time: 2015-09-05_09:23:01 Locale: fr-FR (fr_FR) but not with LO 5.0.1.2 Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale : fr-FR (fr_FR) OS: Windows 7 Home Premium
(In reply to Julien Nabet from comment #5) > Yousuf: just to be sure, do you use brand new profile? Yes the dbg daily builds use their own internal profile.
Can't reproduce with windows 32bit build from 37a04c46c5de7. Nor on Linux with - 32ab58fb0bbe7e76536758de66e4fb13f4870ef. Trace looks like stack corruption of some sort - nasty to chase that; its possible but unlikely that a valgrind trace would help. I would suspect Java too for this sort of case FWIW ;-) Then again - quite possibly the segv you get in gdb there is one that Java creates, expects and handles (java uses SEGVs for various reasons) - can you do 'continue' and if it doesn't exit but crashes again - get a new backtrace ? When you say it crashes - were you using a SEGV under gdb to mean a crash ? they are far from all crashes =)
(In reply to Michael Meeks from comment #8) > Trace looks like stack corruption of some sort - nasty to chase that; its > possible but unlikely that a valgrind trace would help. I would suspect Java > too for this sort of case FWIW ;-) > Then again - quite possibly the segv you get in gdb there is one that Java > creates, expects and handles (java uses SEGVs for various reasons) - can you > do 'continue' and if it doesn't exit but crashes again - get a new backtrace > ? Unfortunately i didnt follow this? All i did was execute './soffice --backtrace' from the commandline and it crashed and dropped me back at the command prompt. Here is the output at the commandline. warn:ucb.ucp.gio:28666:1:ucb/source/ucp/gio/gio_content.cxx:400: ignoring GError "The specified location is not supported" for <vnd.sun.star.job:alias=UpdateCheck> warn:ucb.ucp.gio:28666:1:ucb/source/ucp/gio/gio_content.cxx:400: ignoring GError "The specified location is not supported" for <service:com.sun.star.deployment.ui.PackageManagerDialog>
Created attachment 118512 [details] dbg build backtrace 2
Yousuf: perhaps I'm wrong but the bt still shows "???". It might be useful to use the other way to retrieve a bt, ie attach soffice process to gdb https://wiki.documentfoundation.org/Development/How_to_debug#Attaching_to_the_soffice.bin_process then when it segfaults with "???", type "c" (for "continue") until you have something else than "???". At this moment, just type "bt". Hope it helps.
> All i did was execute './soffice --backtrace' Unfortunately that's not going to work in this case. Almost certainly this is a deliberate, Java produced SEGV and its different from the one you want to catch, it should be handled silently. We should really improve our 'gdbtrace' series of commands to catch and print in a nice loop there; however ... quickly prototyping that here with a while (1) etc. etc. doesn't work at all well for me. A quick hack might be to add a good number of: bt thread apply all bt continue bt thread apply all bt continue to the program/gdbtrace file to get several backtraces - thanks !
(In reply to Julien Nabet from comment #11) > Yousuf: perhaps I'm wrong but the bt still shows "???". > It might be useful to use the other way to retrieve a bt, ie attach soffice > process to gdb > https://wiki.documentfoundation.org/Development/ > How_to_debug#Attaching_to_the_soffice.bin_process I tried that method and not sure what to do next as LO has halted and at the (gdb) commandline. The wiki says "After attaching to the soffice.bin process gdb stops the program." and i have no idea what that is supposed to mean. Well it seems the crash should be reproducible by all when libreoffice is run in backtrace mode (./soffice --backtrace).
(In reply to Yousuf (Jay) Philips from comment #13) > ... > I tried that method and not sure what to do next as LO has halted and at the > (gdb) commandline. The wiki says "After attaching to the soffice.bin process > gdb stops the program." and i have no idea what that is supposed to mean. > > Well it seems the crash should be reproducible by all when libreoffice is > run in backtrace mode (./soffice --backtrace). Sorry, I forgot to say that once in gdb it indeed halt, so you just have to type "c" (for continue) and so reproduce the pb. In fact, I quoted this because it seemed that it might be difficult to retrieve an useful bt in this specific case with the usual way.
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
What's the status here? I don't see any reason to keep a bibisectRequest on it until it's independently confirmed on a recent master build. Removing for now. If it's still a problem with a current master and can be confirmed by both Jay and another person, toss it back into bibisectRequest and I'll see what I can do.
Still reproducible on Linux Mint 17.1 XFCE. Version: 5.2.0.0.alpha0+ Build ID: 8a086a2c08efe2037957b959109e72b8bb3e27b7 Threads 2; Ver: Linux 3.13; Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-12-07_08:17:11 Locale: en-US (en_US.UTF-8)
hmm; so if you have a debug build; perhaps it would be better to generate a core file =) if you can ensure you're running soffice from a write-able directory and do: ulimit -c unlimited and run it until it crashes. Then we should have a core.12345 file. You should be able to load that in gdb: gdb /path/to/soffice.bin core.12345 thread apply all backtrace And then we'll have the detail we need to chase the real crash; not the Java related SEGV =) Thanks !
(In reply to Michael Meeks from comment #18) > hmm; so if you have a debug build; perhaps it would be better to generate a > core file =) if you can ensure you're running soffice from a write-able > directory and do: yes i have a write-able directory. > ulimit -c unlimited i ran this at the commandline and it didnt output anything. > and run it until it crashes. then i ran `./soffice --backtrace` and caused the crash > Then we should have a core.12345 file. but no core.12345 file was created.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20161010
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20161108