Description: When Calc NLP Solver is started for non-linear optimization, which takes more than an hour (DS-PSO agent) it is working. In parallel, a Write document is opened, edited, saved, and closed. When optimizations finish and "Keep Results" button is pressed Calc crashes. Opening LibreOffice gives a dialog for documents recovery. The optimization results are kept during the crash. Optimization results are not lost, but after the general crash of LibreOffice other open documents are also affected. I have looked at Calc's nlpsolver module and I see some document lock instructions. I suppose that such locking may be causing the crash. Steps to Reproduce: 1. Open Calc and start NLP solver with DE-PSO agent for long-run optimization. 2. Open Write document, write something, save the document, close the document. 3. Wait for optimization to finish and press the Keep Results button. Actual Results: General crash of LibreOffice. Expected Results: Optimization results to be kept and Calc document to be editable and savable. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.6.2 Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; VCL: osx Locale: en-US (en_BG.UTF-8); UI: en-US Calc: threaded
Would it be possible you retrieve a stacktrace (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#macOS:_How_to_get_debug_information)? Also, would you have a ods file (and ideally minimal step by step process) to reproduce this?
Created attachment 173831 [details] First crash report dialog box.
Created attachment 173832 [details] Second crash report dialog box.
Created attachment 173833 [details] Third crash report dialog box.
(In reply to Julien Nabet from comment #1) > Would it be possible you retrieve a stacktrace (see > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#macOS: > _How_to_get_debug_information)? > > Also, would you have a ods file (and ideally minimal step by step process) > to reproduce this? It seems it is not a regular Mac OS application crash. I was not giving a report dialog box. I did screenshots of the dialog boxes shown during the crash.
argh, there's no stacktrace in the screenshots :-( Would it be possible you attach the ods file? Of course, don't forget to sanitize it (see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission)
(In reply to Julien Nabet from comment #6) > argh, there's no stacktrace in the screenshots :-( > Would it be possible you attach the ods file? > Of course, don't forget to sanitize it (see > https://wiki.documentfoundation.org/QA/Bugzilla/ > Sanitizing_Files_Before_Submission) Only these dialogs were shown during the crash. I did a screenshot of each one. Sure, I will upload the working documents. All the information inside them is public.
Created attachment 173834 [details] Calc file with the model for the optimization. The NPL Solver does not keep meta information for the optimization model. Target cell and variable cells are marked with background colors.
Created attachment 173835 [details] Dummy Write file created, edited, saved, and closed during the optimization. It is a dummy file. Any other file can be created, edited, saved, and closed during the optimization process in order to reproduce the crash.
Now you've provided the file, could you provide minimum step by step process to launch NLPSolver and indicate each parameter/value/option you've chosen to trigger a long treatment so people can give it a try?
OK. I will describe the minimal steps. I have tried the same in Windows. It has created a crash report. crashreport.libreoffice.org/stats/crash_details/9f53626a-95d0-4ee1-9a25-31480f63b6ea
I have done short video about this crash: https://youtu.be/HxBAKCE1nwg
Created attachment 173840 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today (+enable-dbgutil), I got a crash when clicking on "solve" button to launch the process, no need to use Writer and a dummy file.
I don't know if it's the same pb but let's put this one to NEW since there's something wrong here. Stephan: thought you might be interested in this one.
My LibreOffice installation is an older version than what I am using on Mac. The crash is similar on both platforms. This is my Windows LibreOffice info: Version: 6.3.3.2 (x64) Build ID: a64200df03143b798afd1ec74a12ab50359878ed CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL
(In reply to Julien Nabet from comment #14) > Stephan: thought you might be interested in this one. shrug; as long as the reproduction steps are not written down here I'm more than unlikely to take a look
Step by step process to reproduce the pbs: - retrieve https://bugs.documentfoundation.org/attachment.cgi?id=173834 and open thefile - click on cell M2 - select Tools/Solver - select radio button "Minimum" - click just at right of "By changing cells" - type this: $G$2:$I$9;$J$2:$K$2 - click "Options" button and check you use "DEPS Evolutionary Algorithm" (it should be the case by default) - Click "Ok" to close "Options" dialog - Click on "Solve" button => just some seconds after, I got a crash but if you don't have, you can keep on to try to reproduce the initial crash from Todor - let the solving treatment processing and open a brand odt file - type anything - Save with save as and choose any filename - Close the odt file => LO goes back to the Calc part with solving process - Click "stop" button - Click "Ok" button => crash
Thanks, Julien. It is possible to have a new bug in the latest version of the source code. I see that parallel working in Write during the optimization process in Calc leads to crashes in older versions of LO. In my case, if I do not work in Write the optimization process goes smooth and without crashes.
(In reply to Julien Nabet from comment #17) > Step by step process to reproduce the pbs: > - retrieve https://bugs.documentfoundation.org/attachment.cgi?id=173834 and > open thefile > - click on cell M2 > - select Tools/Solver > - select radio button "Minimum" > - click just at right of "By changing cells" > - type this: > $G$2:$I$9;$J$2:$K$2 > - click "Options" button and check you use "DEPS Evolutionary Algorithm" (it > should be the case by default) > - Click "Ok" to close "Options" dialog > - Click on "Solve" button > => just some seconds after, I got a crash That is due to > java.lang.NullPointerException > at net.adaptivebox.deps.behavior.PSGTBehavior.generateBehavior(PSGTBehavior.java:100) > at net.adaptivebox.deps.DEPSAgent.generatePoint(DEPSAgent.java:126) > at com.sun.star.comp.Calc.NLPSolver.DEPSSolverImpl.solve(DEPSSolverImpl.java:169) which ultimately gets translated into a C++ com::sun::star::uno::RuntimeException (via a BridgeRuntimeError thrown from Bridge::handle_java_exc, bridges/source/jni_uno/jni_uno2java.cxx, and then via the C++ UNO bridge), thrown from within > xSolver->solve(); in ScOptSolverDlg::CallSolver (sc/source/ui/miscdlgs/optsolver.cxx), which remains uncaught.
Stephan, I think that this is a new bug, which we (generally me) have introduced last two weeks. Please, take a look at this video: https://youtu.be/HxBAKCE1nwg The result of the steps shown in this video is written in the crash report: https://crashreport.libreoffice.org/stats/crash_details/9f53626a-95d0-4ee1-9a25-31480f63b6ea I will fix the bugs with the Java null pointer exceptions. Please, do not waste time with them. The crash shown in the video is something more general and it exists in the code base for a longer time.
(In reply to Todor Balabanov from comment #20) > Stephan, I think that this is a new bug, which we (generally me) have > introduced last two weeks. Please, take a look at this video: > https://youtu.be/HxBAKCE1nwg > > The result of the steps shown in this video is written in the crash report: > https://crashreport.libreoffice.org/stats/crash_details/9f53626a-95d0-4ee1- > 9a25-31480f63b6ea > > I will fix the bugs with the Java null pointer exceptions. Please, do not > waste time with them. The crash shown in the video is something more general > and it exists in the code base for a longer time. Just to adjust expectations: I quickly looked into this issue after Julien provided both (a) a backtrace that suggested the issue /might/ be related to code I know something about (the C++ UNO bridge), and (b) readable instructions how to reproduce the issue. I'm more than unlikely to look further into this issue if there are no readable instructions how to reproduce the "real" issue (assuming that there is no good reason to deliver a video instead of written instructions) and there is no strong evidence that the "real" issue might be related to code I know something about.
(In reply to Stephan Bergmann from comment #19) > ... > That is due to > > > java.lang.NullPointerException > > at net.adaptivebox.deps.behavior.PSGTBehavior.generateBehavior(PSGTBehavior.java:100) > > at net.adaptivebox.deps.DEPSAgent.generatePoint(DEPSAgent.java:126) > > at com.sun.star.comp.Calc.NLPSolver.DEPSSolverImpl.solve(DEPSSolverImpl.java:169) > > which ultimately gets translated into a C++ > com::sun::star::uno::RuntimeException (via a BridgeRuntimeError thrown from > Bridge::handle_java_exc, bridges/source/jni_uno/jni_uno2java.cxx, and then > via the C++ UNO bridge), thrown from within > > > xSolver->solve(); > > in ScOptSolverDlg::CallSolver (sc/source/ui/miscdlgs/optsolver.cxx), which > remains uncaught. Thank you! I wonder how you retrieved these info. I put a System.out.println before and after line 100 of PSGTBehavior.java and I confirm this. (In reply to Todor Balabanov from comment #20) > Stephan, I think that this is a new bug, which we (generally me) have > introduced last two weeks. Please, take a look at this video: > https://youtu.be/HxBAKCE1nwg > > The result of the steps shown in this video is written in the crash report: > https://crashreport.libreoffice.org/stats/crash_details/9f53626a-95d0-4ee1- > 9a25-31480f63b6ea > > I will fix the bugs with the Java null pointer exceptions. Please, do not > waste time with them. The crash shown in the video is something more general > and it exists in the code base for a longer time. I may be wrong but I think the crash I got must be first fixed so we're be able to reproduce yours with full debug.
Julien sounds reasonable.
The same crash in Linux: https://crashreport.libreoffice.org/stats/crash_details/2d5fa6a6-2868-4f8b-8cd8-272a95b749e2
It seems the crash in Linux happens because of some locking: void ScDocShell::LockPaint_Impl(bool bDoc) { if ( !m_pPaintLockData ) UnlockPaint_Impl(true); // now UnlockDocument_Impl(0); } }
Created attachment 174001 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today + https://gerrit.libreoffice.org/c/core/+/119744 to avoid my crash, I could reproduce the crash. I haven't waited for the end of the solving, I've just stopped then press Ok button. (of course after having done the Writer part).
The null pointer bug was newly introduced and I hope we have solved it. The LockPaint_Impl bug stays in the code base for a much longer time. I did reproduce it in stable releases of LO under Mac OS, Ubuntu, and Windows. It exists in many different builds of LO.
fix for crash here https://gerrit.libreoffice.org/c/core/+/120175
Great! Only a single line of code. I will test it on my machine.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ec867a13baaa43791d8bacf4e8c1b96aadb6aa8a tdf#143534 Crash in Calc NLP Solver It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/da1c79205777357d2b22626b4985dfcd7e014236 tdf#143534 Crash in Calc NLP Solver It will be available in 7.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
had a fix committed, so assume the problem is solved. If the same problem still occurs, please reopen this one. If you're not sure whether it is the same problem, please open a new bug and mention this bug instead.