Created attachment 109955 [details] running two copies of this will exit when you activate the macro-attached cells This macro spreadsheet works really slick SOME of the time. But it only allows ONE instance of the document to be open at a time. If two copies are opened, then the macro crashes (soffice.bin process dies) almost immediately. The macro does an account lookup when you type something in the D column. Actually, this document crashes fairly easily anyway, even if only one copy is open. The crash seems to mostly happens if you go BACK to a D column cell that you previously touched. Moving forward by just doing data entry generally works rather well. I haven't been able to "predict" a crash by doing a particular sequence, but selecting multiple D column cells and then clicking again on a single D column cell often triggers the crash. I'm sure there are several bugs involved here. The focus of this bug report should be running multiple instances of VBA simultaneously. I THINK it crashes more easily in Linux than in Windows, but it does crash in both. Our global organization uses Excel for finances, but we are moving to LibreOffice in some of our branches. We updated the VBA macros so that they work in both Excel and Calc. In normal practice, we would like to have multiple copies of this spreadsheet template running simultaneously as we do data entry. Note: in order to make any debugging changes to the macro code, MS Office Excel MUST be used. LibreOffice calc is designed NOT to be able to change VBA code. Ignore Modules1-5. The VBA in question is in Module:AccountLookups and Sheet1 and the form frmListPicker.
I can reproduce crash with Version: 4.4.0.0.alpha2+ Build ID: d273a60bfdbf9bb7623bed38667ec0647753157c TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-11-20_03:05:21
Created attachment 109966 [details] gdbtrace
Created attachment 110029 [details] gdbtrace This gdb was created using a single document, entering four accounts, and then moving up through them one by one. Crashed when I got to the first account. Using 4.4.0 development build with some additional SAL_WARN statements added.
Created attachment 110068 [details] gdbtrace I took a slightly different approach this time. Again using a single document, this time I manually filled in a few D column cells without using the macro. Then I turned the macro on and moved to a pre-populated cell. It crashed immediately.
Created attachment 110141 [details] reduced macro code to the bare minimum I worked on isolating the part of the code that seems to be causing the crash. It seems to crash when a call is made to txtValue_Change() - which a textbox element calls when the value changes. Private Sub txtValue_Change() 'If this function is completely blank, it seems to not crash MsgBox (txtValue) 'this is enough to cause the crash End Sub txtValue_Change() is not called when clicking on an empty cell, which is why I can do normal data entry OK.
Created attachment 110142 [details] gdbtrace trace from Macro crashing copy2.xls. Even more SAL_WARN statements added.
A note in the code reminded me that txtValue_changed() was NOT always called in Linux when assigning a value to it, although I noticed that it IS changing now. So I ran a bibisect. Crash didn't happen before this function was implemented. 7735ac016add3b7e4b96d6017919a828e3271a0a is the first bad commit commit 7735ac016add3b7e4b96d6017919a828e3271a0a Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Thu Oct 17 04:55:26 2013 +0000 source-hash-923312f67fbf120158f01c2c0e588af38fc22364 commit 923312f67fbf120158f01c2c0e588af38fc22364 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Thu May 9 14:46:17 2013 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Fri May 10 17:04:39 2013 +0100 adjust magic binary index that identifies the theme name res id because libreoffice inserted a bunch of extra resources since fork point. We should get rid of these ids entirely and e.g. at least instead use the filename number as the the id instead which would be a little less painful. Change-Id: I5d0a3b5e60dbe448164bdff25d46171a1ed4d55e (cherry picked from commit 8e9bcdb73adf7b544299bb57fcce5423b43cc058) :100644 100644 f549eaf15411dc0b37a0800e8dadc797106518e8 c2eb091c94e53f35fe1bad4ce2bc76079178a4dd M autogen.log :100644 100644 cc3714998b018d71bdb6fd72ad645270dbc4703f 6f1d9c97acb4fd6aa006acc835fa9daea580088b M ccache.log :100644 100644 b714626ba537591ad2ff98c6cc4142b32c7a35d4 782a0735945bd60378f049482425058644f75dbf M commitmsg :100644 100644 85f9078e2750959e0f5a04d1f28ad8fbc8613d36 ed8e583f1f2de85d02865d68ecf555d4b023c637 M dev-install.log :100644 100644 6012fd52cb6048d9a0a10ffe58d1d63cc88c251c 630ef49633f42af73d3413045c6527f68c594d5e M make.log :040000 040000 4450e5fb967379167f92444df4655734e1de052a 4ebe5a10aef8efe9a3d4a187fbffe81b62118115 M opt justin@justin-Latitude-D830:~/git/bibisect-43all$ git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect good 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # good: [8ad82bc1416a07501651e8d96fe268e47d3931d3] source-hash-13821254f88d2c5488fba9fe6393dcf4ae810db4 git bisect good 8ad82bc1416a07501651e8d96fe268e47d3931d3 # good: [d084d250b04446535ca1d7c29cf2062e6bd042b3] source-hash-688f72e3a2c3ef923389bbd21f6aea3afe1114db git bisect good d084d250b04446535ca1d7c29cf2062e6bd042b3 # bad: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0 git bisect bad c2069a369d738078124812312d51f21ea1ce2421 # bad: [e2a9149a7723f4e00eb3cafe466e204e5da19e9c] source-hash-2ede6c95e6481c92cc199e7d74fd36c841636304 git bisect bad e2a9149a7723f4e00eb3cafe466e204e5da19e9c # good: [f1fda5341557321cf4953c0d5dc6ffe262f1b545] source-hash-ee8323e2280c72eb5cc9ec0257164154b2580a78 git bisect good f1fda5341557321cf4953c0d5dc6ffe262f1b545 # bad: [7735ac016add3b7e4b96d6017919a828e3271a0a] source-hash-923312f67fbf120158f01c2c0e588af38fc22364 git bisect bad 7735ac016add3b7e4b96d6017919a828e3271a0a # good: [3894c5d4955cdef8187b35e8d3eeb37ecdf8d7b7] source-hash-a2c34b3d9ac2d7e43e52846308cc63447fd51f23 git bisect good 3894c5d4955cdef8187b35e8d3eeb37ecdf8d7b7 I'll bet it was introduced here: author Noel Power <noel.power@suse.com> 2013-04-23 17:13:37 (GMT) committer Noel Power <noel.power@suse.com> 2013-05-09 13:11:18 (GMT) commit 4bad1a8e314269f2538133eb241135a225ac3f4f (patch) tree b608bf79ffd0b34bd74d142cd89bb58cda498618 parent 3fb03cc873280c49e04c59062c1ad21b53c7f5df (diff) support api initiated change_event for combox & textbox Change-Id: Iff51a184792e9d12accb902df1772fc07589443b
Created attachment 110161 [details] gdbtrace bibisect: confirming that "support api initiated change_event for combox & textbox" definitely is the change that triggered the crashing. The changed added a call to "fireChangeEvent()". Doing a "step into the macro code", the crash happens when txtValue_change()'s "Exit Sub" is evaluated. gdb crashes vary in their reports of the specific crash point, but a recurring place is at /data/justin/git/libreoffice/basic/source/sbx/sbxvar.cxx:207 207 delete pCst; // who knows already, onto which thoughts someone comes?
Changing status to Linux only. Windows doesn't have the problem clearly exhibited in Linux.
Created attachment 110162 [details] gdbtrace sorry, I've missed the compression part of my previous traces. They are just tar's....
since the bibisect (comment #7), my gdb traces are based on the 4.1 code from Noel's commit. I was able to get Windows to crash once with this test case - but it doesn't happen nearly as often.
From the backtrace I think this is just a duplicate of now fixed bug 86843. Can you try again with that fix in place and see if i can be reproduced?
I am no longer seeing crashes since the two dependency bugs were fixed. Closing this bug.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]