Created attachment 47024 [details] Apple stacktrace of crash using datasource navigator Scenario : It is possible to navigate datasources declared to LibreOffice via the F4 function button. Once this window is activated, e.g. because you have a pre-registered datasource such as an address book, you can drag and drop data to a Writer document from the datasource window using the mouse by selecting the data from a table and dropping it onto a Writer document. A Copy Data wizard then appears to guide you in deciding how to insert the data : as a Table, as Text, or as Fields. If you choose, as a Table, the user is presented with a dialog window that allows for setting the formatting of the data within the table and applying predetermined styles. Once these have been set, a table is created and the data copied into it, with the chosen styles applied. Environment : LibreOffice 3.4rc1 on Mac OSX 10.6.7 Connection to mysql datasource via the native mysql connector extension 1.0.1. Steps to reproduce : 1) Open a new writer document 2) Press Shift+F4 (this is the key combo for a Macbook, for a PC, just press F4) 3) The datasource navigation window appears within the main application window at the top in a separate frame. 4) Click on one of the source tables that appears in the lefthand pane of the datasource navigation window. 5)Select data from the table that is displayed. To select all data from the table, click in the upper lefthand corner cell of the grey table boundary. As an aside, this doesn't actually select all of the data, only that visible within the space displayed in the frame, but I'll open a separate bug for that. 6)The copy data wizard opens, choose Table and follow on to creation of the table and insertion of data. 7) Press carriage return with the cursor underneath the recently created table to insert a new table. 8) Try to repeat the same operation as above, with another table. 9) After several repeated operations, LibreOffice just crashes in an apparently random way. Will attach Apple stacktrace. Alex
No idea whether this is related to the crash, but profiling with Apple's Shark in the LibreOffice process leading up to the crash indicates that there are illegal ops taking place : 0x27b72399 0x06 in connectivity::OSQLParseNode::impl_parseNodeToString_throw(rtl::OUStringBuffer&, connectivity::SQLParseNodeParameter const&) const +473 0x27b723f4 0x820900 in connectivity::OSQLParseNode::impl_parseNodeToString_throw(rtl::OUStringBuffer&, connectivity::SQLParseNodeParameter const&) const +564 Alex
raising priority to critical
In fact, LibO crashes after one or two drag and drop operations in a systematic manner. Alex
Problem does not occur in NeoOffice 3.2 patch2. Alex
Can reproduce also in OOo-dev 3.4.0m0. Alex
Reproducible also on OOo 3.2.1. Alex
Changing module to Database. Writer just happens to be the container in which the problem is displayed. Alex
re-title to reflect mac specific issue. Is there no chance you can get a better (complete) gdb backtrace for this ? a full backtrace would have a dozen call frames of who called whom when the crash happened :-) Also - if you could compile a version with debug symbols and run it under valgrind on the mac that'd be wonderfully helpful and get this fixed far faster.
(In reply to comment #8) > re-title to reflect mac specific issue. Is there no chance you can get a better > (complete) gdb backtrace for this ? a full backtrace would have a dozen call > frames of who called whom when the crash happened :-) > > Also - if you could compile a version with debug symbols and run it under > valgrind on the mac that'd be wonderfully helpful and get this fixed far > faster. I would love to be able to, but : 1) Compiling a normal build on a Mac is still fraught with problems for me, and thus obtaining a debug build even more so. Assuming I could solve (1): 2) Valgrind does not support/like LO's input dialogs on Mac...so that kind of scuppers that idea. I tried this already with one of my first builds, and it was a lamentable fail. Alex
Created attachment 52841 [details] stack trace Stack trace made against build from master on 28/10/2011
Comment on attachment 52841 [details] stack trace Please ignore this attachment, put it on wrong bug report.
I can no longer reproduce this behaviour on current (28/10/2011) build from master, so closing as worksforme. Alex