debug log would be nice: https://wiki.documentfoundation.org/Development/How_to_debug

Have connected to MariaDB on OpenSUSE Leap 42.1 64bit rpm Linux.
Installed the packages
MyODBC
unixODBC

In odbcinst.ini I set this:
[MySQL]
Description = ODBC Driver for MySQL
Driver = /usr/lib64/libmyodbc5.so

In odbc.ini I set this
[MySQL-test]
Description = MySQL database test
Driver = MySQL
Server = localhost
Database = libotest
Port = 3306
Socket =
Option = 3
Charset = UTF8

Only error: LO is looking for libodbc.so.1, but there is only a libodbc.so.2 on my system. So I put a link from usr/lib64/libodbc.so.1 to usr/lib64/libodbc.so.2.

Have tried this, could input data - so I couldn't confirm this bug.

You wrote,

"Have connected to MariaDB ... In odbcinst.ini ... Driver = /usr/lib64/libmyodbc5.so"

Thanks, but I think this is the MySQL driver you're pointing to above, not the MariaDB driver (i.e. "lib my odbc..").

The MariaDB driver is named: libmaodbc.so  (lib ma odbc..).

---

FYI, I tried to use the MySQL driver here but it crashed when I tried to Test the connection.

Which database engine are you using, MariaDB or MySQL?

(In reply to robert from comment #2)
> Have connected to MariaDB on OpenSUSE Leap 42.1 64bit rpm Linux.
> Installed the packages
> MyODBC
> unixODBC
> 
> In odbcinst.ini I set this:
> [MySQL]
> Description = ODBC Driver for MySQL
> Driver = /usr/lib64/libmyodbc5.so
> 
> In odbc.ini I set this
> [MySQL-test]
> Description = MySQL database test
> Driver = MySQL
> Server = localhost
> Database = libotest
> Port = 3306
> Socket =
> Option = 3
> Charset = UTF8
> 
> Only error: LO is looking for libodbc.so.1, but there is only a libodbc.so.2
> on my system. So I put a link from usr/lib64/libodbc.so.1 to
> usr/lib64/libodbc.so.2.
> 
> Have tried this, could input data - so I couldn't confirm this bug.

(In reply to Joel Madero from comment #1)
> debug log would be nice:
> https://wiki.documentfoundation.org/Development/How_to_debug

Ok, I read thru this a bit.  I might need some help getting this.  I tried to start these but all of them just printed usage:

libreoffice5.2 --base --enable-debug 
libreoffice5.2 --base --enable-debug --enable-selective-debuginfo="sw/ xmloff/"
libreoffice5.2 --base --enable-dbgutil

And I tried this but got "No such file or directory"

./autogen.sh --enable-debug


Do I need to try and build LibreOffice from source?

(In reply to Howard Johnson from comment #3)
> "Have connected to MariaDB ... In odbcinst.ini ... Driver =
> /usr/lib64/libmyodbc5.so"
> 
> Thanks, but I think this is the MySQL driver you're pointing to above, not
> the MariaDB driver (i.e. "lib my odbc..").
> 
> The MariaDB driver is named: libmaodbc.so  (lib ma odbc..).

There is no special libmaodbc available for my system (OepnSUSE 42.1 64bit rpm Linux). I use MyODBC-unixODBC instead. Compiled nothing here by myself.
> 
> ---
> 
> FYI, I tried to use the MySQL driver here but it crashed when I tried to
> Test the connection.
> 
> Which database engine are you using, MariaDB or MySQL?

MariaDB 10.0.27-12.1
UnixODBC 2.3.1-3.2

So there must be something special with your installed ODBC-configuration.

(In reply to robert from comment #5)
> (In reply to Howard Johnson from comment #3)
> > "Have connected to MariaDB ... In odbcinst.ini ... Driver =
> > /usr/lib64/libmyodbc5.so"
> > 
> > Thanks, but I think this is the MySQL driver you're pointing to above, not
> > the MariaDB driver (i.e. "lib my odbc..").
> > 
> > The MariaDB driver is named: libmaodbc.so  (lib ma odbc..).
> 
> There is no special libmaodbc available for my system (OepnSUSE 42.1 64bit
> rpm Linux). I use MyODBC-unixODBC instead. Compiled nothing here by myself.
> > 
> > ---
> > 
> > FYI, I tried to use the MySQL driver here but it crashed when I tried to
> > Test the connection.
> > 
> > Which database engine are you using, MariaDB or MySQL?
> 
> MariaDB 10.0.27-12.1
> UnixODBC 2.3.1-3.2
> 
> So there must be something special with your installed ODBC-configuration.

Thanks.  

I have tried to use the MySQL ODBC driver, but with it I could not get ODBC to work at all, i.e. isql would not connect.  

To solve this I got the libmaodbc MariaDB ODBC connector here:

  https://mariadb.com/products/connectors-plugins
     click <Download MariaDB ODBC driver>

  https://mariadb.com/my_portal/download/connector-odbc
     Then I selected for Debian/Ubuntu, and:
       mariadb-connector-odbc-2.0.12-ga-linux-x86_64.tar.gz
         Inside is:
            /lib
              libmaodbc.so

So I copied the libmaodbc.so file into /usr/lib/x86_64-linux-gnu/odbc/libmaodbc.so, and set Driver=/usr/lib/x86_64-linux-gnu/odbc/libmaodbc.so in odbcinst.ini.  Then isql began to work.

Perhaps there is something special about this connector driver, but it is the one from MariaDB, and I could not get ODBC to work with MariaDB until I installed it.

I'm also working on trying to get some sort of debug log, but am stalled because at the moment I don't know how to do this.  Will keep working on it.  Thanks for your help.

I just upgraded to unixODBC 2.3.4.  But the results are the same: crash.

Also I'm using Maria 10.1 which could have changed something I suppose.

  your Maria version: 10.0.27-12.1
  mine, via this command:
    mysql --version 
       Ver 15.1 Distrib 10.1.18-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Previously, our unixODBC versions were very close:

  yours  2.3.1-3.2
  mine   2.3.1-3

Have tried it a little bit more.

libmaodbc.so: 
I couldn't get it work with the binaries. 
One version (2.0.12, libmadoc.so 1.6 MB) gives the error: file not found
Other version (2.0.12, libmadoc.so 2.0 MB) gives the error: memory allocation error.
I won't install it through the source-code.

Tested all the special differences in our odbcinst.ini and odbc.ini. Worked with all the parameters you have given - but always the same way as without these parameters.

Couldn't reproduce any error here with OpenSUSE 42.1 64bit rpm Linux.

To retrieve a backtrace on Linux, you can use this link:
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace

Created attachment 127958 [details]
gdbtrace.log  of trying to register and open a new LO ODBC database

Hope this is the right thing for you.  I've never done this before.

bt is ok, thank you for your feedback.

I have edited the title to mention that Mariadb is the environment, because this is WFM in a mysql and mysql odbc connector environment.

@Howard :

- you might have more luck trying to ask for help on the Debian forums as there probably aren't many of us in Base QA using Mariadb over ODBC (with the exception of perhaps Julien)?

You don't state whether the LibreOffice you are using is the Jesse-provided one, or else the TDF-distributed DEBs ?

My immediate suspicion would be that the version of LO you are using has not been compiled against the same version of the mariadb connector client library source code. The only way to know this is to see if there is a log of the compile options somewhere in the LO packages you have installed.

This should not be in NEW status without independent QA confirmation, resetting to NEEDINFO, please set back to UNCONFIRMED once you have provided the requested information.

(In reply to Alex Thurgood from comment #13)
> @Howard :
> 
> - you might have more luck trying to ask for help on the Debian forums as
> there probably aren't many of us in Base QA using Mariadb over ODBC (with
> the exception of perhaps Julien)?
>...

I'm dealing far less than before Base bugs because:
1) for this case specifically, it seems we're still in transition between Mysql and MariaDB (I don't remember details with C and C++ driver and license)
2) we don't upgrade to a newer hsqlDB version because target is Firebird
3) Firebird is still experimental because of some bugs even with Firebird 3.0 (eg: building in MacOS)
4) Reports components are also obsolete

@Juilen : Thanks for the update, and quite agree, the whole mysql/mariadb support is all a bit of a mess at the moment (as indeed are other parts of Base as you mention).


@Howard : my inexpert reading of your trace log would seem to show that there is an incompatibility in the ODatabaseMetaData.cxx code with what the driver is expecting, or announcing, as to its capabilities.

FWIW, bug 46259 is still opne, i.e. nothing has progressed so far on the rewrite of the connector C++ to use mariadb connector C code instead. Perhaps the ODBC connector shares some common ancestry here ?

For an example of the potential for an compatibility with Mariadb client library, see also bug 83656

Just some thoughts.
Since you didn't install MariaDb odbc driver from Debian repo with apt but with tar.gz file from official website, perhaps there's something lacking.

I didn't try to reproduce the problem but on my system, ldd mariadb-connector-odbc-2.0.12-ga-linux-x86_64/lib/libmaodbc.so 
gives this:
	linux-vdso.so.1 (0x00007ffdf37fb000)
	libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 (0x00007eff25701000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007eff253fd000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff2505f000)
	libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007eff24e55000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007eff24c38000)
	/lib64/ld-linux-x86-64.so.2 (0x0000557394653000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007eff24a32000)

if you apt-file all of these referenced files, you'll find a package for them except for linux-vdso.so.1 which is a bit specific

apt-file search libodbcinst.so.2 gives odbcinst1debian2
apt-file search libm.so.6 gives libc6
idem for libc.so.6, libpthread.so.0, ld-linux-x86-64.so.2 and libdl.so.2
apt-file search libltdl.so.7 gives libltdl7

To sum up, do you confirm these packages are installed:
odbcinst1debian2, libc6 and libltdl7 ?

(In reply to Alex Thurgood from comment #16)
> FWIW, bug 46259 is still opne, i.e. nothing has progressed so far on the
> rewrite of the connector C++ to use mariadb connector C code instead.
> Perhaps the ODBC connector shares some common ancestry here ?

(In reply to Julien Nabet from comment #14)
> 1) for this case specifically, it seems we're still in transition between
> Mysql and MariaDB (I don't remember details with C and C++ driver and
> license)

Since this is about connecting through an ODBC driver, this is completely unrelated to the idea of rewriting the NATIVE SDBC driver to not use the GPLed MySQL C++ connector.

I wouldn't be too surprised if the MariaDB libmaodbc didn't implement
 SQLGetInfo(... SQL_FILE_USAGE ...)
or did it incorrectly. Cannot be sure until I take a good look at it, though. isql likely doesn't care about SQL_FILE_USAGE

(In reply to Howard Johnson from comment #0)

> [mariadb]
> Description	 = Maria DB
> Driver 		 = /usr/lib/x86_64-linux-gnu/odbc/libmaodbc.so
> Setup		 = /usr/lib/x86_64-linux-gnu/odbc/libodbcmyS.so
> UsageCount  	 = 1

The "Driver" and "Setup" entries are inconsistent: you use driver from MariaDB, but setup from MySQL; I wonder it that's not the source of the crash. Please try to use *both* from MariaDB, no mixing.

The backtrace would be far more useful if you installed the libreoffice-dbg package (same version as your installed LibreOffice), or used a debug version of libreoffice, e.g. from one of the directories that ends with "-dbg" at http://dev-builds.libreoffice.org/daily/master/ (since these are builds of master / alpha versions, exercice care and caution).

Lionel:
I retrieved sources of MariaDB odbc.
In file ma_connection.c, in this function::
SQLRETURN MADB_DbcGetInfo(MADB_Dbc *Dbc, SQLUSMALLINT InfoType, SQLPOINTER InfoValuePtr,
                          SQLSMALLINT BufferLength, SQLSMALLINT *StringLengthPtr, my_bool isWChar)

I noticed this:
   1169   case SQL_FILE_USAGE:
   1170     MADB_SET_NUM_VAL(SQLUINTEGER, InfoValuePtr, SQL_FILE_NOT_SUPPORTED, StringLengthPtr);
   1171     break;
...

Would this patch help?
diff --git a/connectivity/source/drivers/odbc/ODatabaseMetaData.cxx b/connectivity/source/drivers/odbc/ODatabaseMetaData.cxx
index 65336c2..992f3b5 100644
--- a/connectivity/source/drivers/odbc/ODatabaseMetaData.cxx
+++ b/connectivity/source/drivers/odbc/ODatabaseMetaData.cxx
@@ -50,6 +50,16 @@ ODatabaseMetaData::ODatabaseMetaData(const SQLHANDLE _pHandle,OConnection* _pCon
         try
         {
             m_bUseCatalog   = !(usesLocalFiles() || usesLocalFilePerTable());
+        }
+        catch(SQLException& )
+        { // doesn't matter here
+        }
+        catch(RuntimeException& )
+        {
+            m_bUseCatalog = true;
+        }
+        try
+        {
             OUString sVersion = getDriverVersion();
             m_bOdbc3        =  sVersion != "02.50" && sVersion != "02.00";
         }

(In reply to Julien Nabet from comment #21)
> Lionel:
> I retrieved sources of MariaDB odbc.
> In file ma_connection.c, in this function::
> SQLRETURN MADB_DbcGetInfo(MADB_Dbc *Dbc, SQLUSMALLINT InfoType, SQLPOINTER
> InfoValuePtr,
>                           SQLSMALLINT BufferLength, SQLSMALLINT
> *StringLengthPtr, my_bool isWChar)
> 
> I noticed this:
>    1169   case SQL_FILE_USAGE:
>    1170     MADB_SET_NUM_VAL(SQLUINTEGER, InfoValuePtr,
> SQL_FILE_NOT_SUPPORTED, StringLengthPtr);
>    1171     break;
> ...

Try changing on this line 1170 "SQLUINTEGER" to "SQLUSMALLINT". If my guess is right, it will solve the problem.

I don't know how to build MariaDB odbc driver since there's no instructions about building
Here's the output of cmake:
julien@debian:~/lo/bugs/103077_mariadb/mariadb-connector-odbc-2.0.12-ga-src$ cmake ./
-- The C compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Looking for floor
-- Looking for floor - not found
-- Looking for floor in m
-- Looking for floor in m - found
CMake Error at CMakeLists.txt:118 (MESSAGE):
  MariaDB not found

However, I can propose this patch on https://github.com/MariaDB/mariadb-connector-odbc

I submitted a request here:
https://github.com/MariaDB/mariadb-connector-odbc/pull/12

The Lionel's fix has been pushed!
See https://github.com/MariaDB/mariadb-connector-odbc/pull/12

A test case has been created by the maintener, see https://jira.mariadb.org/browse/ODBC-61?jql=
In this page, we can read:
Fix Version/s:
3.0.0, 2.0.13

So FIXED in the odbc connector and NOTOURBUG.

Thank you Lionel!

Created attachment 128140 [details]
LO Base ODBC setup trace

Today I discovered that I could get a trace of the ODBC calls as they were occurring leading up to this crash.  From this I think Base might be crashing inside LO BASE, and not inside of the ODBC manager nor inside the ODBC driver.  

To trace: In the unixODBC gui turn on Tracing from the driver manager, or add the following lines to odbcinit.ini:

[ODBC]
Trace=1
ForceTrace=1
TraceFile=/tmp/Trace.txt
TraceLibrary=libodbctrac.so


From my trace just now (which I will attach) it appears the crash is happening after ODBC call originating in LGetInfo.c line # 554.  Here is the very last entry from the trace showing that the ODBC call completed successfully:

-----------------------------------------------------
[ODBC][3715][1477058411.956470][SQLGetInfo.c][554]
                Entry:
                        Connection = 0x3808a20
                        Info Type = SQL_FILE_USAGE (84)
                        Info Value = 0x7ffc36990c4e
                        Buffer Length = 2
                        StrLen = 0x7ffc36990c06

[ODBC][3715][1477058411.956513][SQLGetInfo.c][617]
                Exit:[SQL_SUCCESS]
------------------------------------------------------

(Sorry if I've been quiet for awhile.  I've been working on trying to follow your leads as quickly as I could, but I'm slow because I have to do a lot of extra reading because of how new to Linux I am, e.g. I had to read a bunch about shared libraries, and learn about cmake and how to use it (especially when it fails), and also freshen my rusty knowledge of c, and scant knowledge of ODBC. 

I figured out how to get the ODBC connector code, and have been going through it to try and understand it.

Created attachment 128142 [details]
results of ldd and apt-file commands on libmaodbc.so

In my non-expert analysis it appears that everything is in place as you asked me to check.  Attached is the information I collected for you.

(In reply to Julien Nabet from comment #18)
> ... ldd
> mariadb-connector-odbc-2.0.12-ga-linux-x86_64/lib/libmaodbc.so 
> gives this:
> 	linux-vdso.so.1 (0x00007ffdf37fb000)
> 	libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2
> (0x00007eff25701000)
> 	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007eff253fd000)
> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff2505f000)
> 	libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007eff24e55000)
> 	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007eff24c38000)
> 	/lib64/ld-linux-x86-64.so.2 (0x0000557394653000)
> 	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007eff24a32000)
> 
> if you apt-file all of these referenced files, you'll find a package for
> them except for linux-vdso.so.1 which is a bit specific
> 
> apt-file search libodbcinst.so.2 gives odbcinst1debian2
> apt-file search libm.so.6 gives libc6
> idem for libc.so.6, libpthread.so.0, ld-linux-x86-64.so.2 and libdl.so.2
> apt-file search libltdl.so.7 gives libltdl7
> 
> To sum up, do you confirm these packages are installed:
> odbcinst1debian2, libc6 and libltdl7 ?

A couple of answers to your comments:

(In reply to Lionel Elie Mamane from comment #20)
> I wouldn't be too surprised if the MariaDB libmaodbc didn't implement
>  SQLGetInfo(... SQL_FILE_USAGE ...)
> or did it incorrectly. 

It's in odbc_3_api.c:

SQLRETURN SQL_API SQLGetInfo(SQLHDBC ConnectionHandle,
    SQLUSMALLINT InfoType,
    SQLPOINTER InfoValuePtr,
    SQLSMALLINT BufferLength,
    SQLSMALLINT *StringLengthPtr)
{
  MADB_Dbc *Dbc= (MADB_Dbc *)ConnectionHandle;
  SQLRETURN ret;
  if (!Dbc)
    return SQL_INVALID_HANDLE;
  MADB_CLEAR_ERROR(&Dbc->Error);

  MDBUG_C_ENTER(Dbc, "SQLGetInfo");
  MDBUG_C_DUMP(Dbc, InfoType, d);
  ret= Dbc->Methods->GetInfo(Dbc, InfoType, InfoValuePtr, BufferLength, StringLengthPtr, FALSE);

  MDBUG_C_RETURN(Dbc, ret, &Dbc->Error);
}


> The "Driver" and "Setup" entries are inconsistent: you use driver from
> MariaDB, but setup from MySQL; I wonder it that's not the source of the
> crash. Please try to use *both* from MariaDB, no mixing.

Good point.  I found that MariaDB doesn't offer a ODBC setup driver.

I apologize for neglecting to mention that LO Base is also crashing when trying to connect with MDBTools ODBC driver.  I didn't focus on this because I thought it might just make things too complicated and perhaps we should just deal with one crash at a time.  Note that MDBTools uses the exact same library (one library) as both the driver and setup library.  

Later today I hope to take an ODBC call trace of the similar MDBTools crash, and compare it with the MariaDB ODBC call trace crash.

Anyway this setup library you mention appears to only be used by the unixODBC tools to setup/configure odbc.ini and odbcinst.ini.  (But I'm not 100% sure.)  In other words, if it's missing I can't use those tools, (the gui ODBC configuration tools, or odbcinst).  But that notwithstanding isql works when the setup library is missing.  

I wasn't sure what to do when I found the setup library missing but decided a reasonable idea was to use the mysql one, and it worked.  So I'm not 100% sure, but I think the setup libaray only helps setup the configuration parameters in these two confiburation files (/etc/odbc.ini and /etc/odbcinst.ini).  I think that would also make sense because ALL of the setup libraries (except for MDTTools) are named something like: xxxxxS.lo.  (With a "S").


> The backtrace would be far more useful if you installed the libreoffice-dbg
> package (same version as your installed LibreOffice), or used a debug
> version of libreoffice, e.g. from one of the directories that ends with
> "-dbg" at http://dev-builds.libreoffice.org/daily/master/ (since these are
> builds of master / alpha versions, exercice care and caution).

I will work on this.  Sorry I am slow in responding.  I am new to Linux and having to learn much to proceed little.  Thanks for your help!

(In reply to Howard Johnson from comment #28)
> Today I discovered that I could get a trace of the ODBC calls as they were
> occurring leading up to this crash.  From this I think Base might be
> crashing inside LO BASE, and not inside of the ODBC manager nor inside the
> ODBC driver.

While what you write is technically true, I think the ODBC driver overwrites LibreOffice memory when  SQLGetInfo(... SQL_FILE_USAGE ...) is called. Namely it writes, into a LibreOffice-provided pointer (buffer),  4 bytes instead of 2. A patch correcting this was accepted in the driver.

So technically it crashes in LibreOffice code, but it is caused by the ODBC driver.

So please, try with a version of the ODBC driver that is recent enough to include the above accepted patch.

> From my trace just now (which I will attach) it appears the crash is
> happening after ODBC call originating in LGetInfo.c line # 554.  Here is the
> very last entry from the trace showing that the ODBC call completed
> successfully:
> 
> -----------------------------------------------------
> [ODBC][3715][1477058411.956470][SQLGetInfo.c][554]
>                 Entry:
>                         Connection = 0x3808a20
>                         Info Type = SQL_FILE_USAGE (84)
>                         Info Value = 0x7ffc36990c4e
>                         Buffer Length = 2
>                         StrLen = 0x7ffc36990c06
> 
> [ODBC][3715][1477058411.956513][SQLGetInfo.c][617]
>                 Exit:[SQL_SUCCESS]
> ------------------------------------------------------

As I wrote above, it successfully overwrote LibreOffice memory it is not supposed to :)