Description: I have some quite complex forms with several subforms, which when opened stall, with CPU at 100%. This is new in 5.4.0.3 (both direct from Libreoffice and via ubuntu ppa). Version 5.3.4.2 is OK. Steps to Reproduce: 1. Open a form from another form providing a filter 2. Form displays, but goes grey 3. Waits forever, CPU at 100% Actual Results: Not sure what I can add. Expected Results: Nothing - just hangs. Reproducible: Always User Profile Reset: No Additional Info: This happens on non-trivial forms. I don't know exactly what the crucial factor is. Some, mainly simpler, forms open OK. My database is in Mariadb on another system on my LAN. I have tried both MYSQL (native) and MYSQL (JDBC) It would not be at all easy to provide a demo, since the forms are complex, with macros, filtering dialogs, and data resident on another system. IF you have any ideas how I can diagnose this hang, please let me know. I'm willing to install a debug version of LO if needs be. User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.112 Safari/537.36 Vivaldi/1.91.867.48
I starting stripping one of the forms down, removing field by field, and after assuming it was due to the complexity, it turns out to be a date field - no macros and so on, just a date based on a timestamp field in a table, taht used to work and now loops forever. Intriguingly the time field based on the same data doesn't cause a hang. When I get time (a few hours probably) I'll run up a demonstration.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 135055 [details] Self-contained test database The attached file has a form which hangs in 5.4.0.3 but does not in 5.3.4.2. It turns out that something has changed in the underlying data from which my mariadb database is regularly copied which means the (integer) date is, I believe, invalid (so that's my problem to sort out). Nonetheless it shouldn't hang forever. Further, when trying to resolve this I tried to change the format of the control ('replace with'). That didn't work in 5.4.0.3 but does in 5.3.4.2. I guess that is a separate bug.
Confirming also on Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c Threads CPU : 8; OS : Mac OS X 10.12.6; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group
On my master debug-enabled build, attempting to open the form in a lldb session shows this: Process 1237 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV frame #0: 0x000000012ee0b2b4 -> 0x12ee0b2b4: movl (%rsi), %eax 0x12ee0b2b6: leaq 0xf8(%rbp), %rsi 0x12ee0b2bd: vmovdqu %ymm0, (%rsi) 0x12ee0b2c1: vmovdqu %ymm7, 0x20(%rsi) Continuing in the session allows the form to be displayed. Attaching bt from sigsegv and further session output.
Created attachment 135061 [details] Backtrace from lldb session
(In reply to Alex Thurgood from comment #5) > On my master debug-enabled build, attempting to open the form in a lldb > session shows this: > Process 1237 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV > Continuing in the session allows the form to be displayed. > Attaching bt from sigsegv and further session output. Alex, when Java is used, some SIGSEGVs are "normal", as in they are used internally by Java, caught and treated by Java. So, when Java is being used, any SIGSEGV that does not actually crash/abort LibreOffice (meaning it was treated by Java) should be ignored. Unless you are diagnosing a crash/abort caused by a SIGSEGV, I recommend to setup lldb to ignore SIGSEGVs altogether. Not sure how to do it in lldb, but in gdb the command is "handle SIGSEGV noprint nostop pass".
(In reply to Alex Thurgood from comment #5) > Continuing in the session allows the form to be displayed. For complete clarity, does the form display correctly or do you get the same "looping forever with 100% CPU" problem?
(In reply to Lionel Elie Mamane from comment #7) > > Unless you are diagnosing a crash/abort caused by a SIGSEGV, I recommend to > setup lldb to ignore SIGSEGVs altogether. Not sure how to do it in lldb, but > in gdb the command is "handle SIGSEGV noprint nostop pass". OK, will have a look to see if I can integrate that somewhere...
(In reply to Lionel Elie Mamane from comment #8) > (In reply to Alex Thurgood from comment #5) > > > Continuing in the session allows the form to be displayed. > > For complete clarity, does the form display correctly or do you get the same > "looping forever with 100% CPU" problem? Sorry, yes, I should've been clearer - the form loads completely, no looping or 100% CPU usage. It is as if the form has loaded normally - whether this is because the problem is inexistent in master, or whether the debug session allows it to load nonetheless, I have no idea, and I don't have a debug 5432 build to test with which I might be able to compare.
(In reply to tim from comment #3) > Created attachment 135055 [details] > Self-contained test database > > The attached file has a form which hangs in 5.4.0.3 but does not in 5.3.4.2. > > It turns out that something has changed in the underlying data from which my > mariadb database is regularly copied which means the (integer) date is, I > believe, invalid (so that's my problem to sort out). Nonetheless it > shouldn't hang forever. > > Further, when trying to resolve this I tried to change the format of the > control ('replace with'). That didn't work in 5.4.0.3 but does in 5.3.4.2. > I guess that is a separate bug. I'll open a new bug report for the problem that 'replace with' doesn't work.
The problem comes from a date very far in the future, namely approximately in the year 4 111 224. The LibreOffice Date structure cannot handle years after 32767. It is a bug that this leads to an infinite loop. The third column of some table or query is of type INTEGER, and you interpret this as a date (because you bound a Date control to that column?). The value of that column (in some row) is 1501593742. Since you request a date out of it, this is understood as a number of days after 1/1/1900.
(In reply to Lionel Elie Mamane from comment #12) > The problem comes from a date very far in the future, namely approximately > in the year 4 111 224. The LibreOffice Date structure cannot handle years > after 32767. > It is a bug that this leads to an infinite loop. > > The third column of some table or query is of type INTEGER, and you > interpret this as a date (because you bound a Date control to that column?). > The value of that column (in some row) is 1501593742. Since you request a > date out of it, this is understood as a number of days after 1/1/1900. Thanks. I realised after raising the report that the integer content had changed (the data comes from another database originally) - it's now a unix timestamp - so treating it just as a date won't work. I have now worked round that for my own purposes (using a macro to translate - I tried sql functions but not seemed to work for me). However, something has changed from 5.3.4.2, which shows it as a date in 2200 (obviously wrong), to 5.4.3.2 which loops. Others might get caught by having invalid data causing loops. It took me quite a while to work out that the loop might be caused by something this simple (my original form as 30 or so fields on it, 7 sub-forms and so on). I realise this is not exactly a high priority, but endless loops are puzzling to users :)
Your "utimestamp" field of type "integer" seems to be meant as a number of seconds since 1/1/1970 00:00 midnight (aka "UNIX timestamp"). The "SQL way", if you mean a timestamp, is to have a field of type timestamp / datetime. If you "force" LibreOffice to interpret a number as a date or time, then the integer part of a number is "days since 1/1/1900" (or 30/12/1899 or something like that, depending on what application (Calc, Base, ...), what setting, ...) and the fractional part of the number is the time in the day, where 0 is 00:00 midnight, 0.5 is 12:00 noon and 0.9999999... is 23:59:59.99999...
(In reply to tim from comment #13) > However, something has changed from 5.3.4.2, which shows it as a date in > 2200 (obviously wrong), to 5.4.3.2 which loops. Others might get caught by > having invalid data causing loops. Yes, as I wrote, the fact that it creates an infinite loop is a bug. No discussion about that. > I realise this is not exactly a high priority, It is. Endless loop is not acceptable (unless the user programmed an endless loop in Basic or something like that).
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0ccbd58834259cd7724edacde283f4f0f6ed2db0 tdf#110997 protect calls to implBuildFromRelative from year overflow It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=de8c0152157bb32a6df9b6d4ac4102aef8e8a384&h=libreoffice-5-4 tdf#110997 protect calls to implBuildFromRelative from year overflow It will be available in 5.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I've just checked in ubuntu pre-release Version: 5.4.1.1 Build ID: 1:5.4.1~rc1-0ubuntu0.17.04.1~lo0 CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group All OK - Thanks.
Thank you Tim for your feedback. Let's put this one to VERIFIED then.