Bug 37487 - Mac: crash copying data via drag and drop from datasource navigation window
Summary: Mac: crash copying data via drag and drop from datasource navigation window
Status: CLOSED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.4.0 RC1
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-23 00:17 UTC by Alex Thurgood
Modified: 2011-10-29 07:38 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
Apple stacktrace of crash using datasource navigator (62.02 KB, text/plain)
2011-05-23 00:17 UTC, Alex Thurgood
Details
stack trace (66.12 KB, text/plain)
2011-10-28 01:43 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2011-05-23 00:17:24 UTC
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
Comment 1 Alex Thurgood 2011-05-23 09:45:37 UTC
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
Comment 2 Alex Thurgood 2011-05-23 09:46:14 UTC
raising priority to critical
Comment 3 Alex Thurgood 2011-05-23 09:48:01 UTC
In fact, LibO crashes after one or two drag and drop operations in a systematic manner.

Alex
Comment 4 Alex Thurgood 2011-05-24 00:42:58 UTC
Problem does not occur in NeoOffice 3.2 patch2.


Alex
Comment 5 Alex Thurgood 2011-05-24 00:46:21 UTC
Can reproduce also in OOo-dev 3.4.0m0.


Alex
Comment 6 Alex Thurgood 2011-05-24 01:06:09 UTC
Reproducible also on OOo 3.2.1.


Alex
Comment 7 Alex Thurgood 2011-05-24 01:54:24 UTC
Changing module to Database. Writer just happens to be the container in which the problem is displayed.

Alex
Comment 8 Michael Meeks 2011-09-05 07:55:24 UTC
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.
Comment 9 Alex Thurgood 2011-09-05 08:48:15 UTC
(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
Comment 10 Alex Thurgood 2011-10-28 01:43:43 UTC
Created attachment 52841 [details]
stack trace

Stack trace made against build from master on 28/10/2011
Comment 11 Alex Thurgood 2011-10-28 01:46:41 UTC
Comment on attachment 52841 [details]
stack trace

Please ignore this attachment, put it on wrong bug report.
Comment 12 Alex Thurgood 2011-10-28 02:07:40 UTC
I can no longer reproduce this behaviour on current (28/10/2011) build from master, so closing as worksforme.


Alex