Created attachment 91507 [details]
Test data - must be installed as /tmp/tickers.csv
The attached spreadsheet has some complicated Basic macros but they worked in LO 3.6.x, but crash the process using LO 126.96.36.199 (silent abort, followed by an apport run).
I traced it down to a call to the Sort() function, which
calls a UNO function to sort some rows. Here is the relevant
Basic code (which seems to abort only in context):
dim args() as new com.sun.star.beans.PropertyValue
sCellrangeName as String (contains "$A$8:AC47")
oCellRange = oSheet.getCellRangeByName(sCellrangeName)
oCellRange.Sort(args()) 'never returns, process aborts
Steps to reproduce (Unix only, sorry):
1. Download the attached "tickers.csv" into /tmp/tickers.csv
(this path is hard-coded in the demo program)
2. Open the attached j.ods spreadsheet. Enable macros.
3. (Click the Design Mode ON/OFF icon if necessary to exit
design mode -- working around bug 73293)
4. Click the yellow "Reload tickers.csv" button
Click through a few MsgBox displays.
If it does not crash, repeat - it always crashes by the 2nd try.
The code is located in Basic macro module j.ods -> Standard -> SortUtils (search for "DEBUG BEFORE sort")
Current behavior: Fatal process abort
Expected behavior: Should work or give a useful error message
Operating System: Ubuntu
Version: 188.8.131.52 release
Created attachment 91508 [details]
j.ods - spreadsheet demonstrating the crash
apport collected the following about the crash:
Created attachment 91553 [details]
bogus (please ignore)
Created attachment 91554 [details]
Stack traceback, etc. (from appport crash report).
I don't get a full blown crash but I get a lock up after the first run. That being said, requesting expert advice on this one as I don't know if it's LibreOffice or the macro causing the issue.
Noel - should we push this one to NEW?
Tested with Version: 184.108.40.206.0+
Build ID: ca88a0ea6ed7277e8522d83458e3cfb975fcfb7d
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-07-25_10:06:25
Inadmissible value or data type.
Division by zero.
Calc didn't crash.
Any indication of the location of the divide by zero?
I see a crash (spontaneous process abort) inside the built-in Sort function, no in user code.
Build ID: 0ad283adb51b3a1bb777e6341e61541d4bffaa44
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-07-21_07:30:30
(In reply to comment #7)
> Any indication of the location of the divide by zero?
if 100*(Stock-Strike)/Stock > MaxPctITM then
Stock = 0
I have no clue why Raal gets a macro error (divide by zero) and not the crash I see. Please confirm that the "Steps to reproduce" were performed exactly, as there are indeed Basic macro bugs which can be found -- but irrelevant to LO crashing.
I'm going to attach a new demo spreadsheet (j2.ods) and a new backtrace.
This newer spreadsheet has cleaned-up macro code and runs reliably on OO4.1
With LO 4.3.2 (build date 8/18/2014) it gets a SIGSEGV in libsvllo.so (see the backtrace).
Using latest 4.3.2 build from 8/18/2014.
Please try this sequence:
1. Download tickers.csv and move to /tmp (required by the macro code)
2. Download j2.ods and run
/path/to/libreofficedev220.127.116.11.0 --backtrace j2.ods
3. Click the yellow button and wait for screen refresh
Click the yellow button again
Click the yellow button again (crashes on the 3rd time)
Created attachment 104848 [details]
j2.ods -- updated demo spreadsheet (instructions in comment #9)
Created attachment 104849 [details]
gdb traceback using j2.ods and LO 18.104.22.168.0+ build 2014-08-17_22:48:01
now I can reproduce crash with Version: 22.214.171.124.0+
Build ID: 25459cb0c9afdf46c3d90ae8ba0b6ffb375f67da
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-08-17_22:48:01
I can reproduce crash with Version: 126.96.36.199.alpha0+
Build ID: e379401618268ed7f7f5885a36b90e1f4f6cd4af
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-08-18_05:51:03
Please repair j2.ods- CSV file path doesn't containt /tmp/tickers.csv (Proto_csvpath does not exist (/home/jima/Jts/tickers.csv;/home/jima/IBJts/tickers.csv;\\Vboxsvr\root\home\jima\Jts\tickers.csv;\\Vboxsvr\root\home\jima\IBJts\tickers.csv)).
Setting as new.
Created attachment 104861 [details]
j2.ods -- update#3 of demo spreadsheet (instructions in comment #9)
Replacing j2.ods with version which looks in /tmp for the tickers.csv file
(the previous version looked in places used in production)
On pc Debian x86-64 with master sources updated today, I got a crash at first click, here's main part of bt:
#3 0x00002aaaaf5fd639 in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<SvtListener**, std::__cxx1998::vector<SvtListener*, std::allocator<SvtListener*> > >, std::__debug::vector<SvtListener*, std::allocator<SvtListener*> > >::_Safe_iterator (this=0x7fffffff0180,
__i=<error reading variable: Cannot access memory at address 0x9999999999999999>, __seq=0x75405a0) at /usr/include/c++/4.9/debug/safe_iterator.h:149
#4 0x00002aaaaf5fbfdc in std::__debug::vector<SvtListener*, std::allocator<SvtListener*> >::end (this=0x75405a0) at /usr/include/c++/4.9/debug/vector:236
#5 0x00002aaaaf5fab18 in SvtBroadcaster::Normalize (this=0x7540598) at /home/julien/compile-libreoffice/libreoffice/svl/source/notify/broadcast.cxx:28
#6 0x00002aaaaf5fb9ca in SvtBroadcaster::Broadcast (this=0x7540598, rHint=...) at /home/julien/compile-libreoffice/libreoffice/svl/source/notify/broadcast.cxx:124
#7 0x00002aaace1881a2 in ScBroadcastAreaSlotMachine::BulkBroadcastGroupAreas (this=0x2c4ead0)
#8 0x00002aaace187cbc in ScBroadcastAreaSlotMachine::LeaveBulkBroadcast (this=0x2c4ead0) at /home/julien/compile-libreoffice/libreoffice/sc/source/core/data/bcaslot.cxx:1196
#9 0x00002aaace3a18df in ScBulkBroadcast::~ScBulkBroadcast (this=0x7fffffff0570, __in_chrg=<optimized out>)
#10 0x00002aaace5f8352 in ScTable::DeleteSelection (this=0x2aaadc872010, nDelFlag=..., rMark=..., bBroadcast=true)
#11 0x00002aaace41650d in ScDocument::DeleteSelection (this=0x2c45f68, nDelFlag=..., rMark=..., bBroadcast=true)
#12 0x00002aaaceb34f76 in ScDocFunc::DeleteContents (this=0x2b0b5c0, rMark=..., nFlags=..., bRecord=true, bApi=false)
#13 0x00002aaacf01d5f7 in ScViewFunc::DeleteContents (this=0x30a2378, nFlags=..., bRecord=true)
Eike: I noticed broadcast part on bt but in svl, any idea?
Running with valgrind discloses a couple of problems, both of which I think indicate real bugs:
1. Valgrind reports some 8-byte reads which extend 4 bytes beyond the end of malloc'd space. This would cause unpredictable garbage to be returend in the last 4 bytes, and might possibly explain some Basic macro bugs I've been chasing which vanish when print statements are put in. The 8 vs. 4 byte lengths might indicate a bug in some low-level casts related to platform word-size.
This was previously reported but rejected as "NOTABUG" because the offending code is somewhere in Phython bindings. I don't see how it can not be a bug.
Please see https://bugs.freedesktop.org/show_bug.cgi?id=78513
2. Today I re-ran the test for the present bug under Valgring using the option --free-fill=DE, which causes all free'd heap block to be filled with 0xDE values. Doing this made the demo behave very differently -- I got several Basic errors I never saw before. The implication is that LO is referencing memory *after* it has been freed onto the heap.
In summary, I strongly recommend running under valgrind and tracking down and removing all references to undefined (i.e., not currently allocated) memory.
I've got a cleaner valgrind run, and got the attached trace. The main thing of interest is:
Conditional jump or move depends on uninitialised value(s)
==12738== at 0x158DEF48: ??? (in /usr/lib/libreoffice/program/libvclplug_gtklo.so)
1. Copy <instdir>/program/soffice to soffice_patched in the same directory.
2. At line 107 or thereabouts, add --track-origins=yes --free-fill=DE to
the valgrind command line, so it looks like this:
VALGRINDCHECK="valgrind --tool=$VALGRIND --trace-children=yes $valgrind_skip --num-callers=50 --error-limit=no --track-origins=yes --free-fill=DE"
3. Download the tickers.csv and t2.ods demo files from this bug
4. <instdir>/program/soffice_patched --valgrind t2.ods >log 2>&1
5. (patience...) Click the yellow button. Repeat when everything stops.
Hopefully it will segfault, but if not a valgrind error will be reported.
If a pop-up says a copy/paste did not work, click 'Retry' (this occurs when some Basic macro code thinks an operation it just performed had no effect -- which might or might not be an LO bug, but in any case this does not usually happen when not running under valgrind)
After a long while, look in the log file for valgrind errors
Created attachment 110805 [details]
valgrind log showing conditional jump depending on uninit data
Created attachment 110806 [details]
valgrind log showing conditional jump depending on uninit data
Created attachment 110823 [details]
Valgrind trace with master sources
On pc Debian x86-64 with master sources updated today, I retrieved a Valgrind trace with symbols.
Migrating Whiteboard tags to Keywords: ( Need_Advice -> needAdvice)
On pc Debian x86-64 with LO Debian package 188.8.131.52 (RC1), I don't reproduce this now.
Jim: could you give a new try with recent LO version (last stable one is 5.1.3)?
The 2nd demo (from comment #9) does not crash with 184.108.40.206
However there are some strange warnings written to the terminal about "Icons too large" and "Unknown event notification". I'll try on Master and file a separate bug report if they persist.
Thanks for following up. This bug report can be closed.
'needsConfirmationAdvice' is only used for unconfirmed bugs. Removing it from this bug.