Bug 52310 - Calling Relations tool with LO Base and mysql native connector appears to freeze LO pushing user to force kill the app
Summary: Calling Relations tool with LO Base and mysql native connector appears to fre...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.5.5.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Connectivity
  Show dependency treegraph
 
Reported: 2012-07-20 13:04 UTC by Alex Thurgood
Modified: 2018-12-15 19:51 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
apple crash trace after forced kill (312.19 KB, text/plain)
2012-07-20 13:04 UTC, Alex Thurgood
Details
Lldb session full bt (17.40 KB, text/plain)
2017-11-09 13:54 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2012-07-20 13:04:13 UTC
Created attachment 64429 [details]
apple crash trace after forced kill

Using the Oracle provided mysql native connector extension.

Using LibreOffice 3.5.5.3 
Version ID : 7122e39-92ed229-498d286-15e43b4-d70da21

Mac OSX 10.7.4

1) Open an ODB file that uses the native mysql connector extension from Oracle to connect to a mysql server (mine's locally hosted on the same machine)

2) Click on the menu entry Tools > Relations

What happens :
3) LO goes into "beachball" mode, requiring  forced kill.

What should happen :
3) The relations dialog should open and allow the user to set up relations between the tables of the database.

Attaching apple stack trace provided by Apple crash reporter.

Alex
Comment 1 Alex Thurgood 2012-07-20 13:08:25 UTC
This is also reproducible in LO 3.3.4 on Mac OSX
Comment 2 Alex Thurgood 2012-07-20 13:29:06 UTC
Tested also with my own build from master :
Version 3.7.0.0.alpha0+ (Build ID: 042686d)

Same problem.


Alex
Comment 3 Alex Thurgood 2012-07-20 13:41:43 UTC
Reproducible also on Windows XP with LO 3.3.4

Alex
Comment 4 Alex Thurgood 2012-07-20 13:44:25 UTC
Changed platform to all after testing on Windows.

Alex
Comment 5 Alex Thurgood 2012-07-20 17:13:02 UTC
Just for comparative purposes, if I use the JDBC connector, then the Relations dialog gets called, displayed, and is usable.


Alex
Comment 6 Alex Thurgood 2012-07-23 07:11:18 UTC
More experimentation.

I finally discovered that the Relationship menu entry will actually show up, but it took 16 minutes or so to get there on my MacbookPro with OSX Lion (10.7.4). In the meantime LO appears to remain frozen and Apple's system indicates that the app is not responding.

One possible reason for this is that LO fetches all of the relations for all of the databases hosted by the server !!

The irony of the situation is that for the particular database I wanted to call up the relationship dialog on, there are no previously existing relationships, so a user is lead to believe that the application has just died.

I remember seeing an option to filter out the unwanted databases somewhere, I will try that and see if it makes a difference. 



Alex
Comment 7 Alex Thurgood 2012-07-23 07:21:14 UTC
Changing subject headline to better reflect the problem.

The corresponding wait using a JDBC connector is less than 30 seconds.
Comment 8 Alex Thurgood 2012-07-23 07:36:49 UTC
Setting the database filter speeds things up to about the same performance as the JDBC connector _without_ filtering, so a workaround, but performance-wise still not good, this is after all a C++ connector which is supposed to be integrated into the LO environment and not have the performance hit of Java UNO / JNI calls.


Lowering priority and importance.


Alex
Comment 9 Alex Thurgood 2012-07-23 07:40:31 UTC
PS : All tests carried out with Oracle Mysql Connector extension, since my current same build as master compiled connector causes LO to crash while attempting to pass the ID/pwd parameters to the db server.


Alex
Comment 10 Alex Thurgood 2012-07-23 07:42:32 UTC
(In reply to comment #7)
> Changing subject headline to better reflect the problem.
> 
> The corresponding wait using a JDBC connector is less than 30 seconds.


That should read, less than **3** seconds.

Alex
Comment 11 Alex Thurgood 2012-07-23 07:47:54 UTC
Just to sum up :

MySQL Oracle Native Connector extension : 

- unfiltered database list = 16 min to display Relationships dialog
- filtered database list = approx 30 seconds to display Relationaships dialog




MySQL JDBC Connector 5.1.18 :

there is no need to filter the database list, it is apparently prefiltered by the driver = less than 3 seconds to display Relationships dialog


Tested on LO Master, Version 3.7.0.0.alpha0+ (Build ID: 8c05d8b)


Alex
Comment 12 Alex Thurgood 2015-01-03 17:40:43 UTC
Adding self to CC if not already on
Comment 13 QA Administrators 2016-01-17 20:03:47 UTC Comment hidden (obsolete)
Comment 14 Alex Thurgood 2016-01-19 14:18:38 UTC
Still present in 

Version: 5.0.3.2
Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75
Locale : fr-FR (fr.UTF-8)

OSX 10.11.2
Comment 15 QA Administrators 2017-03-06 14:15:14 UTC Comment hidden (obsolete)
Comment 16 Alex Thurgood 2017-06-27 10:13:24 UTC
Testing of this is blocked by bug 107579
Comment 17 Xisco Faulí 2017-07-13 10:41:56 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue
Comment 18 Alex Thurgood 2017-09-15 14:18:14 UTC
Bug still present in 

LO5412 OSX 10.12.6
Comment 19 Julien Nabet 2017-09-24 15:52:31 UTC
On pc Debian x86-64 with master sources updated 2 days ago, I could open the relationship part but I noticed this on console:
warn:legacy.osl:3698:3698:connectivity/source/commontools/dbmetadata.cxx:332: DBG_UNHANDLED_EXCEPTION in bool dbtools::DatabaseMetaData::supportsRelations() const
    type: com.sun.star.sdbc.SQLException
    message: supportsIntegrityEnhancementFacility: feature not implemented.
    context: N12connectivity6mysqlc17ODatabaseMetaDataE

Here is the path:
1) bool DatabaseMetaData::supportsRelations() const
https://opengrok.libreoffice.org/xref/core/connectivity/source/commontools/dbmetadata.cxx#322

2) sal_Bool SAL_CALL ODatabaseMetaData::supportsIntegrityEnhancementFacility()
https://opengrok.libreoffice.org/xref/core/mysqlc/source/mysqlc_databasemetadata.cxx#395

3) mysql-connector-cpp/driver/mysql_metadata.cpp
bool
MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility()
{
        CPP_ENTER("MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility");
        throw sql::MethodNotImplementedException("MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility");
        return false; // This will shut up compilers
}

I don't know if mariadb c connector implements this or not but it seems that we'll be stuck at least until we upgrade mysql c++ connector or patch it locally.

Lionel: I tried to search a newer mysql c++ connector on Oracle website (+ a free account), I found 1.1.9 but https://dev.mysql.com/downloads/connector/cpp/ provides a tar with only include files.
Comment 20 Lionel Elie Mamane 2017-09-25 10:33:33 UTC
(In reply to Julien Nabet from comment #19)

> Lionel: I tried to search a newer mysql c++ connector on Oracle website (+ a
> free account),

On the downloads, there is a small "no thanks, just let me download" below the big "login" and "sign up" boxes.

> I found 1.1.9 but
> https://dev.mysql.com/downloads/connector/cpp/ provides a tar with only
> include files.

Choose "Source Code" as Operating System instead of "Linux".
Comment 21 Julien Nabet 2017-09-25 13:08:59 UTC
(In reply to Lionel Elie Mamane from comment #20)
> ...
> On the downloads, there is a small "no thanks, just let me download" below
> the big "login" and "sign up" boxes.
I got an Oracle account but you're right!

> ...
> Choose "Source Code" as Operating System instead of "Linux".
Indeed, I had missed it.

I downloaded 1.1.9 version but I still see:
bool
MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility()
{
	CPP_ENTER("MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility");
	throw sql::MethodNotImplementedException("MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility");
	return false; // This will shut up compilers
}

I took a look to mysql-connector-c++-8.0.5-dmr-src but seems quite different. Moreover, I haven't seen "supportsIntegrityEnhancementFacility" keyword.
Comment 22 Julien Nabet 2017-09-25 19:43:20 UTC
The strange this is on pc Debian x86-64 with master sources updated today, with odb linked to a Mysql db, I could entered Relationship screen and create relationships.
The only thing is LO remembers the last added relation because when  
I saved, reopened the file, only the last added relation was there.
If I add the first one again, save and reopen, both appear.
Now if remove both relations (and keep the tables on the screen), save and reopen, both relations don't appear.
Comment 23 Alex Thurgood 2017-11-09 13:43:01 UTC
Running in a lldb session, I have to interrupt the hung thread, and then running a backtrace, I see this :

* frame #0: 0x00007fff5d147082 libsystem_kernel.dylib`__recvfrom + 10
    frame #1: 0x0000000183ac3a5c libmysqlcppconn.dylib`vio_read(vio=0x000000017fab1980, buf=")", size=4) at violite.c:247
    frame #2: 0x0000000183ac4cbf libmysqlcppconn.dylib`my_real_read(net=0x000000010b3da600, complen=0x00007ffeefbfe110) at net.c:577
    frame #3: 0x0000000183ac4b99 libmysqlcppconn.dylib`my_net_read(net=0x000000010b3da600) at net.c:719
    frame #4: 0x0000000183ac94a1 libmysqlcppconn.dylib`net_safe_read(mysql=0x000000010b3da600) at libmariadb.c:369
    frame #5: 0x0000000183acd51b libmysqlcppconn.dylib`mthd_my_read_query_result(mysql=0x000000010b3da600) at libmariadb.c:2274
    frame #6: 0x0000000183ad8e81 libmysqlcppconn.dylib`mysql_stmt_execute(stmt=0x0000000186e7b9b0) at my_stmt.c:1490
    frame #7: 0x0000000183aa97e3 libmysqlcppconn.dylib`sql::mysql::MySQL_Prepared_Statement::do_query(this=0x0000000186d40ac0) at mysql_prepared_statement.cpp:427
    frame #8: 0x0000000183aa9ca5 libmysqlcppconn.dylib`sql::mysql::MySQL_Prepared_Statement::executeQuery(this=0x0000000186d40ac0) at mysql_prepared_statement.cpp:495
    frame #9: 0x0000000183a9d543 libmysqlcppconn.dylib`sql::mysql::MySQL_ConnectionMetaData::getImportedKeys(this=0x000000010ab8f6f0, catalog=<unavailable>, schema=0x00007ffeefbfe628, table=0x00007ffeefbfe568) at mysql_metadata.cpp:2713
    frame #10: 0x00000001839a6c25 mysqlc.uno.dylib`connectivity::mysqlc::ODatabaseMetaData::getImportedKeys(this=0x00000001804b7d28, catalog=<unavailable>, schema=0x00007ffeefbfe700, table=0x00007ffeefbfe6f8) at mysqlc_databasemetadata.cxx:1251
    frame #11: 0x00000001839a71f2 mysqlc.uno.dylib`non-virtual thunk to connectivity::mysqlc::ODatabaseMetaData::getImportedKeys(this=<unavailable>, catalog=<unavailable>, schema=<unavailable>, table=<unavailable>) at mysqlc_databasemetadata.cxx:0
    frame #12: 0x00000001889de8a6 libdbulo.dylib`(anonymous namespace)::RelationLoader::run(this=0x00000001804d13d0) at RelationController.cxx:334
    frame #13: 0x00000001889ddaa4 libdbulo.dylib`dbaui::ORelationController::loadData(this=0x0000000180483820) at RelationController.cxx:521
    frame #14: 0x00000001889dd521 libdbulo.dylib`dbaui::ORelationController::impl_initialize(this=0x0000000180483820) at RelationController.cxx:230


Not quite sure why ConnectionMetaData::getImportedKeys can't pick up the catalog (unavailable) 

or

 maybe the hang is due to network lookup failing to return a statement result set (frames 1 to 5) ?
Comment 24 Alex Thurgood 2017-11-09 13:53:32 UTC
On resumption after breaking out, the Relations for the entire database schemas are displayed. This would seem to suggest that there is mutex waiting to be released or acquired or a mutex race condition somewhere between retrieving the relationship data and handing off to the drawing of the window and painting of the data.

Enclosing a backtrace that perhaps someone else can better understand than I can.
Comment 25 Alex Thurgood 2017-11-09 13:54:32 UTC
Created attachment 137642 [details]
Lldb session full bt
Comment 26 QA Administrators 2018-12-04 03:48:13 UTC Comment hidden (obsolete)
Comment 27 Alex Thurgood 2018-12-04 10:20:36 UTC
Bug still present in 

Version: 6.3.0.0.alpha0+
Build ID: 284dd58e326e61a5d84bde367e1e4873dd738c76
CPU threads: 4; OS: Mac OS X 10.14.1; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-11-22_23:09:13
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded