Apache OpenOffice (AOO) Bugzilla – Issue 33728
crash when using scripted list box in bug doc
Last modified: 2006-05-31 14:29:06 UTC
open the attched spreadsheet. It contains several sheets, and on every sheet a listbox with the names of all sheets. Selecting an entry in the listbox activates the respective sheet. When doing this a few times (select a list box entry, see the sheet being switched, select another entry, and so on), OOo finally crashes.
accepting
Created attachment 17501 [details] document to reproduce the bug case
fs->ssa: This is yet another instance of a problem we already encountered a few times. Within VCL, WindowEvent listeners are called. Within this call, the VCL control is destroyed for whatever reason. After returning from the call, the control doesn't care or it being destroyed, but continues, for instance with accessing some members ... The solution is pretty easy, using the ImplDelData. I am going to attach a patch, which fixes this, and some other potential areas with the same problem.
Created attachment 17503 [details] proposed patch
fs->ssa: The attached patch fixes the problem in a somewhat broader context. The idea is that there are several controls which notfiy some listeners, following the very same pattern: ImplCallEventListeners( <event_id> ) maSomeHandler.Call( this ) I introduced a Control::ImplCallEventListenersAndHandler, which implements exactly this pattern. Therein, an ImplDelData is used to ensure that that nothing is notified/accessed in case the instance has been destroyed within the first call. Additionally, I modified all occurrences of this pattern in vcl/source/control, which hopefully will spare us some more of this kind of bugs in the future ... Could you please approve/deny this patch for checkin in VCL? Thanks :)
Created attachment 17504 [details] patch II
The new patch fixes another crash, which still sporadically happens after the first patch has been applied (but which is not caused by the first patch). Still, there is one crash left: Now, when you often enough select an entry in the list box, switching sheets this way, and close the document, this sometimes (not always) crashs. Still investigating.
when using the two patches, I cannot provoke a crash on Linux, anymore. However, Windows is still sporadically crashing.
ssa->fs: the first patch looks good, however, please remove the '_' in the parameters of the new method ;) the second patch is missing an ImplRemoveDel() if it was not deleted. Just guessing: the crash upon closing might be due to some handler still being on the stack. So may be some action (like switching the sheets) has to be done asynchronously.
> the first patch looks good, however, please remove the '_' in the parameters of the new > method ;) will do :) > the second patch is missing an ImplRemoveDel() if it was not deleted oops. You're right, will correct this. Thanks for this round, I'll attach a new patch. > the crash upon closing might be due to some handler still being on the stack Unfortunately not :(. It's some extremly strange crash upon destroying an osl::Mutex, which I do not remotely understand :( > So may be some action (like switching the sheets) has to be done asynchronously I suppose this could solve the problem, but it wouldn't solve the root cause, but only the symptoms - would it?
Created attachment 17533 [details] patch III
"patch III" merges the new versions of the previous two.
patch looks good now - of course.... doing things asynchronously is sometimes the only way, but in your case you may be right about the symptoms. didnÄt know about the mutex when I started guessing.
fs->fs: interesting finding: When removing the script events from the buttons contained in the document (context menu -> "Control ..." -> "Events" -> "when initiated"), then the crash-upon-closing-the-document does not happen. Strange.
After struggling with this for more than a week, I made the notification asynchronous ... There were plenty of places (not only the ones addressed in the patch III) which did not survive synchronous notifications (because objects on the stack were killed within the notification). Fixing them all would have been too much hazzle .... fixed in CWS dba17
looks good in m63 -> closing