Bug Hunting Session
Bug 52275 - CRASH - Using Mysql native connector extension and ODB file when passing connection identifiers
Summary: CRASH - Using Mysql native connector extension and ODB file when passing conn...
Status: CLOSED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.6.0.2 rc
Hardware: x86-64 (AMD64) Mac OS X (All)
: high critical
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:3.7.0 target:3.6.1
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-07-19 17:00 UTC by Alex Thurgood
Modified: 2013-06-11 05:33 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
apple crash trace of connector induced crash (91.72 KB, text/plain)
2012-07-19 17:00 UTC, Alex Thurgood
Details
bruote-force patch (537 bytes, patch)
2012-07-20 02:19 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2012-07-19 17:00:09 UTC
Created attachment 64401 [details]
apple crash trace of connector induced crash

Just tested on master build from today 16:23pm. This is a debug enabled build (in theory).

Clean install of the LO-dev application.

Mac OSX Lion 7.4


How to reproduce :
I have a preconfigured ODB file that connects to a locally hosted mysql database server. This connection has served me well thus far with previous versions of LO and the native mysql connector extension for Mac.

When I open the file in LO master, I get the main ODB window. Then I click on Tables and the connection dialogue appears.

I enter my name and password, and press enter.

Crash.

Reproducible every time. Enclosed apple crash trace.

Alex
Comment 1 Alex Thurgood 2012-07-19 17:01:34 UTC
This is a regression over LO 3.3.x and 3.5.x


Alex
Comment 2 Alex Thurgood 2012-07-19 17:21:02 UTC
I forgot to add that the connector is built at the same time as the main dev build.


Will test with Oracle connector download to check.

Alex
Comment 3 Lionel Elie Mamane 2012-07-19 17:56:16 UTC
Reproduced on my libreoffice-3-6 branch.

It seems the internal mysql-connector-c++ and LibreOffice (connectivity/source/drivers/mysql/YCatalog.cxx) are compiled with a different C++ ABI.

The std::__debug::list<> implementationin YCatalog.cxx has a _M_impl._M_size member, but there is none in mysql-connector-c++-1.1.0/driver/mysql_metadata.cpp.

I remember we solved (or merely discussed?) a "problem like that" recently. Ah, I think we decided the "problem" had been solved in gcc proper...

Alex, I'm terribly busy these days; could you please:

1) force a rebuild of connectivity and mysql-connector-c++ (make connectivity.clean mysqlcppconn.clean)

2) rebuild in verbose mode (do not pass option "-s" to make)

3) compare the exact options passed to g++ in connectivity module and in mysqlcppconn module (from the build log)

I expect connectivity compiles with -std=c++11, but mysqlcppconn without.
Comment 4 Lionel Elie Mamane 2012-07-19 18:34:24 UTC
(In reply to comment #3)

> Alex, I'm terribly busy these days; could you please: (...)

Won't be necessary anymore. Found the problem. MySQL C++ connector explicitly compiled in c++98 mode, apparently to work around a GCC bug. Attached patch removes that and fixes this bug (you need to not only make "mysqlcppcon.clean && make mysqlcppconn", but also "make mysqlc && make -o build dev-install").

What do do to about the other GCC bug? I'm not sure. Just ignore it and fail to build with GCC 4.6.1?
Comment 5 Lionel Elie Mamane 2012-07-20 02:19:22 UTC
Created attachment 64413 [details]
bruote-force patch

@mstahl: since you introduced the "force mysqlcppconn to be compiled with -std=c++98", I'd like your input on this, so that we don't reintroduce the problem you solved...

Do we force whole LibO in -std=c++98 (or gnu++98) when compiling with
an affected gcc version and --without-system-mysql-cppconn? How can we detect
whether the version of g++ being used has the bug that led you to forcing
mysqlcppconn in c++98 mode?

Or should we do it the other way round, and force same compilation options
only for those gcc versions that broke c++98/c++11 ABI compatibility?
Comment 6 Not Assigned 2012-07-20 12:29:21 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9931d736edfedb9b82a270d754f1ee8a2b134ec7

fdo#52275: Revert "mysqlcppconn: work around weird gcc issue"
Comment 7 Not Assigned 2012-07-20 12:35:14 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=aeb97e51b05e1dfd6d535704a115213809c707fc&g=libreoffice-3-6

fdo#52275: Revert "mysqlcppconn: work around weird gcc issue"


It will be available in LibreOffice 3.6.1.
Comment 8 Michael Stahl (CIB) 2012-07-20 12:42:05 UTC
so i've reverted that change now (and stupidly forgot to set
Lionel as author in the master commit, but have fixed that
in the -3-6 commit).

however i don't think it's going to make any difference
on Mac OS X because i think the ancient gcc 4.0.1 we use
there doesn't support C++0x anyway, so please test
and perhaps i'll be surprised :)
Comment 9 Alex Thurgood 2012-07-20 15:32:48 UTC
(In reply to comment #8)

> 
> however i don't think it's going to make any difference
> on Mac OS X because i think the ancient gcc 4.0.1 we use
> there doesn't support C++0x anyway, so please test
> and perhaps i'll be surprised :)


OK, will rebuild and test, however Lionel's comments got me thinking, coz the autogen switches I'm using are as follows :

--enable-ext-mysql-connector
--with-libmysql-path=/Users/Shared/LO/mysql-connector-c-6.0.2-osx10.5-x86-32bit


Should I be changing these switches to something else, perhaps ?
The reason I'm using the C library is because mysqlcppconn wouldn't build for me on OSX 10.6.8




Alex
Comment 10 Michael Stahl (CIB) 2012-07-20 15:46:02 UTC
Alex,

it is quite a mystery how this mysql thing is supposed to work anyway;
AFAIK it can be built against a mysql C library or against a
mysql C++ library and both of these have to be on the system.

perhaps one of these happens to work and the other not
(on Mac at least)?

do users have to install some stuff from MySQL on the system
to be able to use the extension with LO?

fwiw, the stack trace you attached seems to indicate that an
exception is thrown somewhere in sql::mysql::MySQL_Driver::MySQL_Driver
and then not caught by anything, resulting in std::terminate.

maybe if you start it from the terminal, it prints out
the type of exception that is thrown.
Comment 11 Lionel Elie Mamane 2012-07-20 17:49:04 UTC
(In reply to comment #10)

> it is quite a mystery how this mysql thing is supposed to work anyway;
> AFAIK it can be built against a mysql C library or against a
> mysql C++ library and both of these have to be on the system.

The C++ library is a wrapper around the C one, and thus uses the C one. This explains why both of them need to be installed.

Alex is using the system's C library, but the C++ one in the LibO sources as external module.

> fwiw, the stack trace you attached seems to indicate that an
> exception is thrown somewhere in sql::mysql::MySQL_Driver::MySQL_Driver
> and then not caught by anything, resulting in std::terminate.

Hmm... Possibly Alex was actually reporting a different problem that the one we just fixed :-|
Comment 12 Alex Thurgood 2012-07-21 09:15:35 UTC
(In reply to comment #10)

Hi Michael,

> it is quite a mystery how this mysql thing is supposed to work anyway;
> AFAIK it can be built against a mysql C library or against a
> mysql C++ library and both of these have to be on the system.
> 
> perhaps one of these happens to work and the other not
> (on Mac at least)?

I could not get the CPP library to work because of version conflicts in libmsyql16, which is why I downloaded the C library from mysql's web site, and then link to that at build time.


> 
> do users have to install some stuff from MySQL on the system
> to be able to use the extension with LO?

No, the mysql connector on Mac has historically included everything that was needed, in order to avoid having to add client libraries to the system. 

As it turns out, Apple's OSX has included a mysql server/client binaries since Leopard 10.5, but even then were/are still prone to version conflicts (since Apple was always more than a step behind with its versions). However, even with those client binaries pre-installed, one still needed to download the libmysqlclient16 libraries in order to build anything with them.



> maybe if you start it from the terminal, it prints out
> the type of exception that is thrown.

I will have a look later on today, after installing my clean build from last night.


Alex
Comment 13 Alex Thurgood 2012-07-21 09:18:19 UTC
(In reply to comment #2)


> 
> Will test with Oracle connector download to check.
> 


So, I forcibly removed the home built connector extension from my yesterday's LO dev build, restarted the app and installed the Oracle Mysql native connector extension downloaded from the AOOo extensions website - what do you know, no crash !!


Alex
Comment 14 Alex Thurgood 2012-07-26 06:36:17 UTC
(In reply to comment #10)

Hi Michael,


> it is quite a mystery how this mysql thing is supposed to work anyway;
> AFAIK it can be built against a mysql C library or against a
> mysql C++ library and both of these have to be on the system.
> 

So, I tried building once more using :


--enable-ext-mysql-connector
--with-system-mysql

and the build fails in mysqlcppconn. I'll open a separate bug issue for that with the build log.



> perhaps one of these happens to work and the other not
> (on Mac at least)?
> 

It appears that the build only completes when the external (MySQL provided source) C libraries are used. 



Alex
Comment 15 Alex Thurgood 2012-07-26 06:42:05 UTC
The link I've added to fdo#45652 is related to someone on Gentoo with build problems similar to what I experienced in the past on Mac OSX, which was the reason why I downloaded the MySQL C source libraries directly from the MySQL web site and pointed my build to them instead.


Alex
Comment 16 Alex Thurgood 2012-07-26 09:28:58 UTC
OK, so did a make clean of mysqlcppconn pointing to external mysql source libraries, it seems to build OK, but throws the following :


Compiling: mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.cpp
/Users/Shared/LO/master/mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.h: In copy constructor 'sql::mysql::MySQL_Warning::MySQL_Warning(const sql::mysql::MySQL_Warning&)':
/Users/Shared/LO/master/mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.h:45: warning: 'sql::mysql::MySQL_Warning::next' will be initialized after
/Users/Shared/LO/master/mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.h:44: warning:   'const sql::SQLString sql::mysql::MySQL_Warning::descr'
/Users/Shared/LO/master/mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.cpp:97: warning:   when initialized here
Making:    mysqlcppconn.lib
Making:    libmysqlcppconn.dylib
/Users/Shared/LO/master/solenv/bin/checkdll.sh -L../../../../../unxmacxi.pro/lib -L/Users/Shared/LO/master/solver/unxmacxi.pro/lib  ../../../../../unxmacxi.pro/lib/libmysqlcppconn.dylib
Checking DLL ../../../../../unxmacxi.pro/lib/libmysqlcppconn.dylib ...
Multiprocessing build is finished
Comment 17 Lionel Elie Mamane 2012-07-26 09:54:13 UTC
(In reply to comment #16)
> OK, so did a make clean of mysqlcppconn pointing to external mysql source
> libraries, it seems to build OK,

When you do that, PLUS you need to rebuild mysqlc and reinstall the extension, is the libmysqlFOO.dylib shipped as part of the extension?

Could you check that the LibO process indeed uses that library, and not the system/default one?
Comment 18 Alex Thurgood 2012-07-27 06:09:16 UTC
(In reply to comment #17)


> When you do that, PLUS you need to rebuild mysqlc and reinstall the extension,
> is the libmysqlFOO.dylib shipped as part of the extension?
> 
> Could you check that the LibO process indeed uses that library, and not the
> system/default one?


Did a pull yesterday and a clean build from a new shell. Will test later on today and report back.


Alex
Comment 19 Alex Thurgood 2012-07-27 16:42:29 UTC
Ho hum,

so now, on a fresh build, with a clean installation and LO user profile (i.e. purged from /User/alex/Library/Application Support/ before installing LOdev) :

the driver appears to be registered, but if I try to connect I get the following error :

A connection for the following URL was requested "sdbc:mysql:mysqlc:127.0.0.1:3306/ipdatabase".

and I can not connect. This error is reminiscent of the passive component registration problems that Stephan fixed with his previous commits, they haven't been reverted (partly or wholly) by any chance ?


Alex
Comment 20 Alex Thurgood 2012-07-27 16:44:45 UTC
(In reply to comment #19)

> 
> the driver appears to be registered, but if I try to connect I get the
> following error :


By "appears to be registered", I mean I can see it in the list of pre-installed extensions.


Alex
Comment 21 Alex Thurgood 2012-07-27 16:56:20 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > OK, so did a make clean of mysqlcppconn pointing to external mysql source
> > libraries, it seems to build OK,
> 
> When you do that, PLUS you need to rebuild mysqlc and reinstall the extension,
> is the libmysqlFOO.dylib shipped as part of the extension?
> 

I found libmysqllo.dylib, which is present in the application in 

LOdev.app/Contents/programs directory.


lsof | grep soffice gives the following :

soffice    1399 alex  txt      REG               14,2    319660 35504633 /Applications/LOdev.app/Contents/MacOS/libmysqllo.dylib


Alex
Comment 22 Lionel Elie Mamane 2012-07-30 18:16:11 UTC
(In reply to comment #21)
> (In reply to comment #17)
>> (In reply to comment #16)

>>> OK, so did a make clean of mysqlcppconn pointing to external mysql source
>>> libraries, it seems to build OK,

>> When you do that, PLUS you need to rebuild mysqlc and reinstall the extension,
>> is the libmysqlFOO.dylib shipped as part of the extension?

> I found libmysqllo.dylib, which is present in the application in 
> 
> LOdev.app/Contents/programs directory.

That's not the one I was looking for; I was looking for libmysql15.dylib or libmysql16.dylib or something like that. My guess is that the the .oxt file which works contains such a file, and the .oxt file that does not work does not contain it.
Comment 23 Lionel Elie Mamane 2013-06-06 14:21:26 UTC
Any news here? If no news / no test on newer LibreOffice, we should close this bug.
Comment 24 Alex Thurgood 2013-06-06 17:43:08 UTC
Hi Lionel,

Slipped under the radar, sorry. Will have a look again this weekend. 

Alex
Comment 25 Alex Thurgood 2013-06-11 05:31:26 UTC
At the moment, this works in my LO 4.0.2, and LO 4.2 master builds with the relevant native mysql connectors, so closing as WFM.


Alex