I tested same problem with LibreOffice.org 3.6.6. It works fine. 
(with same *.odb file, same database, same environment)
For me the database function is critical.
Also most of the businesses use databases and fine operation with databases should be a must.

I have tested it with LO 4.0.2.2, LO 4.0.3.3, LO 4.0.4.2 and 4.1.0.0 Beta 2 - in every tested version of LO 4.* LO crashed immediately when connecting to a mysql-database with UnixODBC. The crash happened directly after input of the right password. I couldn't see any table of the database.
Same file with LO 3.6.6.2 and LO 3.3.4 works right. Doesn't make a difference which Java-version is chosen.
All tested with OpenSUSE 12.3 64bit rpm.
With JDBC the connection to MySQL/MariaDB works.
I set the version to 4.0.2.2, the first I have tested of LO 4.*.

Could one of you provide a backtrace? (see https://wiki.documentfoundation.org/BugReport#How_to_get_a_backtrace_on_Linux)

On pc Debian x86-64 with master sources updated today or with 4.0.3 Debian packages, I don't reproduce this.

Package: libmyodbc
Source: myodbc
Version: 5.1.10-3

Mysql server: 5.5.31-1 -(Debian)

(In reply to comment #3)
> Could one of you provide a backtrace? (see
> https://wiki.documentfoundation.org/
> BugReport#How_to_get_a_backtrace_on_Linux)

I have tried to find a package for a backtrace - don't know, where to get. Must be a package of LO, I think, not a package, that is packed by OpenSUSE, because I am using the LO-packages of libreoffice.org.

When I try to start ./soffice --backtrace, the log-file appears and LO itself won't start.

robert: you must wait a little (it depends on the config but on a i5 with Linux, it's about 30 seconds for me), the time to load share libraries

Created attachment 81081 [details]
Backtrace when opening LO and try to connect to MySQL with ODBC

I have tried to make a backtrace. LO starts, but many errors in the trace. Don't know much about debugging ...
LO crashes after typing the correct password for the ODBC-connection to a MariaDB and pressing the Button "OK".

Great! The important part is from here:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7baebb5 in rtl_uStringbuffer_insert () from /home/robby/Lotest/LO4022/install/opt/libreoffice4.0/program/../ure-link/lib/libuno_sal.so.3
#0  0x00007ffff7baebb5 in rtl_uStringbuffer_insert () from /home/robby/Lotest/LO4022/install/opt/libreoffice4.0/program/../ure-link/lib/libuno_sal.so.3
#1  0x00007fffb35c7dc8 in connectivity::odbc::OTools::getStringValue(connectivity::odbc::OConnection*, void*, int, short, unsigned char&, com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&, unsigned short) () from /home/robby/Lotest/LO4022/install/opt/libreoffice4.0/program/../program/libodbcbaselo.so
#2  0x00007fffb35d137b in connectivity::odbc::ODatabaseMetaDataResultSet::getString(int) () from /home/robby/Lotest/LO4022/install/opt/libreoffice4.0/program/../program/libodbcbaselo.so

Lionel: I took a look to the backtrace but i don't know how it goes from connectivity::odbc::OTools::getStringValue, http://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/odbcbase/OTools.cxx#406
to "rtl_uStringbuffer_insert"
even if I've got the link, I don't know what could be the problem. Any idea to dig?

Robert: do schema or tables, etc. names contain non ascii characters?

Robert: i noticed BT indicated 4.0.2. Would you have some time to try to retrieve a BT with 4.1 beta or 4.2 with a daily build? the goal is to know if we get the same

(In reply to comment #9)
> Lionel: I took a look to the backtrace but i don't know how it goes from
> connectivity::odbc::OTools::getStringValue,
> http://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/
> odbcbase/OTools.cxx#406
> to "rtl_uStringbuffer_insert"

It is one of the aData.append calls. See in include/rtl/ustrbuf.hxx (or in older versions, sal/inc/rtl/ustrbuf.hxx):

OUStringBuffer & append( const sal_Unicode * str, sal_Int32 len)
{
    // insert behind the last character
    rtl_uStringbuffer_insert( &pData, &nCapacity, getLength(), str, len );
    return *this;
}

In a non-completely-debug build (in particular, in a build that is not "turn all optimisations off"), the call to  OUStringBuffer::append is inlined and thus does not appear in the backtrace.

> even if I've got the link, I don't know what could be the problem.

The best is to reproduce in a fully-debug, no-optimisations build. Then look in gdb at the variables and see what is wrong. Maybe len is bigger than the buffer size, maybe str points to something wrong, ...

Thank you Lionel for the explanations. Badfully, http://dev-builds.libreoffice.org/daily/master/Linux-Fedora17-x86_64@4-gcc-4.7-dbgutil/ is empty and I haven't reproduced this for the moment.

Robert: could you export the database (after having emptied the tables so there's nothing confidential) and attach the script to the bugtracker? I'd like to reproduce this since I enabled full debug on my local build.

Created attachment 81090 [details]
Backtrace with LO 4.1.0.0 beta 2

I have only installed the LO 4.1.0.0 beta2. Have made a backtrace.

There are no non-ascii-characters in the table of the database. It is a testdatabase for libreoffice only with one table, 2 fields and 7 rows with an integer-field an name. The whole content is made with LO 3.3.4 ...

Created attachment 81091 [details]
MariaDB - Opening fails in LO 4.* with ODBC - 3.* no problem

Here is the little Database. Couldn't be the database, I think - nearly no content inside ...

4.1 backtrace shows the same rtl_uStringbuffer_insert problem.

Thank you Robert for the export, I'll give to the db a try when come back from day time job.

Robert: even by using your dump, I still don't reproduce this :-(
I'm not sure to have understood all the comments but I noticed you use MariaDb, did you try with Mysql? 
On pc Debian, there's no MariaDb package so I use Mysql Server 5.5.31-1 - (Debian)

Remark: I would prefer using MariaDb if it was present in Debian repositories.

Created attachment 81260 [details]
Backtrace with LO 4.0.3.3, OpenSUSE 12.1, MySQL

I have installed MySQL (instead of MariaDB) on another OpenSUSE-System (12.1 64bit instead of 12.3 64bit the other backtraces were made with). 
Could open the database with LO 3.6.6.2, could create tables etc.
Connection with LO 4.0.3.3 fails after typing the password for the database and click "OK". LO closes immediately.

Cannot reproduce using LibreOffice 4.0.5.0+ (my own dev tree, debug build).
Cannot reproduce using LibreOffice 4.0.3.1 (official TDF build)

All tests with:
 - Debian GNU/Linux amd64 on client (LibreOffice) and server (MySQL)
 - unixodbc 2.2.14p2-5
 - libmyodbc 5.1.10-3
 - MySQL 5.1.66-0+squeeze1

Test done:
 - open .odb
 - click on "Tables" in left pane
 - enter valid password
 - double-click on a table to read the contents

(In reply to comment #18)
> 
> All tests with:
>  - Debian GNU/Linux amd64 on client (LibreOffice) and server (MySQL)
>  - unixodbc 2.2.14p2-5
>  - libmyodbc 5.1.10-3
>  - MySQL 5.1.66-0+squeeze1

Seems the versions in OpenSUSE are a little bit older: unixodbc 2.2.12, libmyodbc 5.1.8
Versins differ a little bit between SUSE 12.1 and SUSE 12.3
> 
> Test done:
>  - open .odb
>  - click on "Tables" in left pane
>  - enter valid password
--- and then comes the crash.
>  - double-click on a table to read the contents
--- couldn't see any tables in both versions.

I have tried to get other packages work (32bit instead 64bit; newer versions of unixodbc). Couldn't connect to MySQL with this packages and LO.
Then tried Edit → Database → Properties → Test Connection.
The messagebox appears: "The connection was established succesfully."
But when I click on "Tables" in left pane LO crashes.

Robert: sorry for this "everytime" question, but could you rename your LO directory profile and give it a new try? It's just to be sure the pb isn't triggered by a buggy element on previous version even I didn't see anything in bt, or missed it, which could indicate this.

(In reply to comment #20)
> Robert: sorry for this "everytime" question, but could you rename your LO
> directory profile and give it a new try? It's just to be sure the pb isn't
> triggered by a buggy element on previous version even I didn't see anything
> in bt, or missed it, which could indicate this.

I hav deleted the LO directory, started LO 4.0.3.3. directory was created new. Started the Database and tried to connect to MySQL with ODBC - crash of LO.

The reporter did use an rpm-package Linux-system. Could be it is a specific bug of this packages?
When I connect to MySQL with LO 3.6.* and ODBC I could see the tables. But I have tried to create a table - didn't work. I switched to JDBC - works. Haven't tried much with LO and external databases, but ODBC seems not to be a good connection, when I use Base.

FWIW, I don't get a crash on OSX with the Actual Technology ODBC driver. So, this could well be Suse version specific ?


Alex

Also no crash for me on Linux 32bit Ubuntu 13.04 Raring Ringtail

mysql 5.5.31-0ubuntu0.13.04.1 (Ubuntu)
unixODBC 2.2.14
libmyodbc_5.1.10-2_i386.deb


Alex

Tested against LO :
Version: 4.2.0.0.alpha0+
Build ID: db56d99f7b66c9f3fe38581829077e7008174c7b

Alex

Also tested against LO Ubuntu supplied :

Version 4.0.2.2 (Build ID: 400m0(Build:2))

Works fine there too.

Alex

Created attachment 83081 [details]
Connect to MariaDB with LO 4.0.0.0.beta1 - works

Created attachment 83083 [details]
Connect to MariaDB with LO 4.0.0.0.beta2 - connected, but wrong characters - SQL fails

Have tested this bug. Seems to be a special with Linux and rpm. 

The bug first appears in LO 4.0.0.0.beta2. The name of the database and the name of the tables are shown with wrong characters. Also they are shown, as if the tables are in two databases. If I try to open one of the tables the table couldn't be opened.

When I try to connect to the database with LO 4.0.0.1 LO crashes immediately.

I have now installed LO 4.1.0.4 from the OpenSUSE-repositories (http://download.opensuse.org/repositories/LibreOffice:/Unstable/openSUSE_12.3/) With this version I can contact to the Maria-DB through ODBC. 
Every LO 4.*-rpm directly from the LO-servers crashes LO immediately.

Hmm... This could be an incompatibility between the UnixODBC that our official releases are compiled with and the one the MyODBC driver is compiled with.

@Caolan, Christan: rumour has it that you are building our official RPM binaries.

One possible explanation of this bug is that they are compiled against an UnixODBC that is binary-incompatible with the one in recent OpenSUSE releases. I'd like to check that out; could I see a comparison of the /usr/include files of UnixODBC on our build machine and on OpenSUSE 12.3?


@robert: please confirm the following.

You use the same MyODBC driver binaries in all tests. These come from the OpenSUSE 12.3 repositories.

hmm, we don't compile the universal builds using the system odbc headers, in fact the Linux-*@*-Release-Configuration-RHEL5-Baseline buildbots have no unixODBC-devel rpm installed at all.

The header which (in theory at least) should be used are those ones in-tree at unixODBC/inc/odbc/

(In reply to comment #31)
> hmm, we don't compile the universal builds using the system odbc headers, in
> fact the Linux-*@*-Release-Configuration-RHEL5-Baseline buildbots have no
> unixODBC-devel rpm installed at all.

> The header which (in theory at least) should be used are those ones in-tree
> at unixODBC/inc/odbc/

Oh, good point. I'll take a look at those. Thanks!

(In reply to comment #30)
> @robert: please confirm the following.
> 
> You use the same MyODBC driver binaries in all tests. These come from the
> OpenSUSE 12.3 repositories.

@lionel:

All I have installed comes from OpenSUSE 12.3-repositories. On the same machine ODBC works with the LO-4.1.0.4 from OpenSUSE, but didn't work with any version from LO directly.

This are the versions from ODBC:
MyODBC-unixODBC-5.1.8-40.3
unixODBC-2.2.12-219.1.1

@vmiklos: as barely-discussed on IRC, this crash has only ever been reproduced on OpenSUSE, nobody attached a backtrace-with-symbols, so I give up and I'm handing off to you as SUSE-person.

Reproduction instructions:

1) Install MySQL or MariaDB, or secure access to a server.

2) Install MyODBC (from OpenSUSE 12.3)

3) In MySQL connection:

   CREATE DATABASE fdo65830;
   use fdo65830;

4) replay the SQL script in attachment 81091 [details]
   (e.g.:
    SCRIPT /path/to/libretest.sql;
   )

5) In ~/.odbc.ini, add something like:

[fdo65830]
Description = fdo#65830 test DB
Driver = MySQL
Server = FILL_ME
Database = fdo65830

6) libreoffice --base
   (use a 4.x TDF build, not OpenSUSE build)

7) "Connect to an existing database"
   Next >>

8) Connection using ODBC (Open Database Connectivityà
   Next >>

9) Browse / Select "fdo65830" in list, OK, Next >> 

10) Use name and password, as/if required
    Next >>

11) Don't register database
    Open database for editing
    Finish

12) You should see a crash, possibly after reentering username/password.
    If not, go to "tables" to force a connection. Still no crash?
    Report here as unreproducible.

(This is an automated message.)

LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched.

You can find out more about MABs and how the process works by contacting libreoffice qa on irc:

 http://webchat.freenode.net/?channels=libreoffice-qa

The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list):

 https://wiki.documentfoundation.org/QA

A crash isn't a security issue, removing security from keyword.

I checked http://download.opensuse.org/distribution/12.3/repo/oss/suse/x86_64/, unixodbc and MyODBC-unixODBC seem the same version than OpenSuse 12.1:
MyODBC-unixODBC-5.1.8-10.2.1.x86_64.rpm
unixODBC-2.2.12-219.1.1.x86_64.rpm

On OpenSuse 13.2 (http://download.opensuse.org/distribution/13.2/repo/oss/suse/x86_64/)
unixODBC-2.3.2-2.2.1.x86_64.rpm
MyODBC-unixODBC-5.1.8-16.1.3.x86_64.rpm

Anyone to give a try with OpenSuse 13.2?

Adding self to CC if not already on

(In reply to Lionel Elie Mamane from comment #34)
> 1) Install MySQL or MariaDB, or secure access to a server.
> 
> 2) Install MyODBC (from OpenSUSE 12.3)
> 
> 3) In MySQL connection:
> 
>    CREATE DATABASE fdo65830;
>    use fdo65830;
> 
> 4) replay the SQL script in attachment 81091 [details]
>    (e.g.:
>     SCRIPT /path/to/libretest.sql;
>    )

Did this on openSUSE 13.2 64-bit with MariaDB 10.0.13, MyODBC 5.1.8, unixODBC 2.3.2.

Running the script was with:
\. /home/test/libretest.sql

> 5) In ~/.odbc.ini, add something like:
 
My ~/.odbc.ini is:

[ODBC Data Sources]

myodbc5     = MySQL ODBC 5.1.8 Driver DSN 

[fdo65830]
Description     = fdo#65830 test DB
Driver          = MySQL
Server          = 127.0.0.1
Database        = fdo65830
Port            = 3306
Socket          =
Option          = 3
ReadOnly        = No

I got help from Mechtilde on IRC and used this guide with modifications: http://mechtilde.de/mysql2ooo20/howtomysql2ooo20.html

I also have an /etc/unixODBC/odbcinst.ini:

[unixODBC]
Description             = ODBC Driver for Unix
Driver          = /usr/lib64/libmyodbc5.so
Setup           = /usr/lib64/libodbcinst.so
FileUsage               = 1
CPTimeout               = 
CPReuse         = 

> 6) libreoffice --base
>    (use a 4.x TDF build, not OpenSUSE build)
> 
> 7) "Connect to an existing database"
>    Next >>
> 
> 8) Connection using ODBC (Open Database Connectivityà
>    Next >>
> 

LibO kept complaining about missing libodbc.so.1, so I had to
link /usr/lib64/libodbc.so.2 /usr/lib64/libodbc.so.1

> 9) Browse / Select "fdo65830" in list, OK, Next >> 

The list is empty.
I'm stuck, what should I do?

(In reply to Beluga from comment #39)
> (In reply to Lionel Elie Mamane from comment #34)
> > 5) In ~/.odbc.ini, add something like:
  
> My ~/.odbc.ini is:
 
> [ODBC Data Sources]
 
> myodbc5     = MySQL ODBC 5.1.8 Driver DSN 
 
> [fdo65830]
> Description     = fdo#65830 test DB
> Driver          = MySQL
> Server          = 127.0.0.1
> Database        = fdo65830
> Port            = 3306
> Socket          =
> Option          = 3
> ReadOnly        = No

> I also have an /etc/unixODBC/odbcinst.ini:

> [unixODBC]
> Description             = ODBC Driver for Unix
> Driver          = /usr/lib64/libmyodbc5.so
> Setup           = /usr/lib64/libodbcinst.so
> FileUsage               = 1
> CPTimeout               = 
> CPReuse         = 

The "Driver = ..." line must match the section name in odbcinst.ini (where you put "unixODBC" which is a bit weird). In other words, the Driver line in my instructions assumes that the corresponding driver section is called "MySQL", but you called it "unixODBC". Also, it seems unusual to me that the "Setup = " line maps to unixodbc's libodbcinst.so instead of a myodbc .so file; my entry has "Setup=libodbcmyS.so"; that's on Debian GNU/Linux FWIW.

> LibO kept complaining about missing libodbc.so.1, so I had to
> link /usr/lib64/libodbc.so.2 /usr/lib64/libodbc.so.1

This sounds like LibreOffice is compiled for a different libodbc than what you have... Usually, when the .so has a different name, it means it is an incompatible version, and simply linking one to the other WILL NOT WORK (or can seem to work, but lead to crashes, data corruption, etc).

(In reply to Lionel Elie Mamane from comment #40)
> The "Driver = ..." line must match the section name in odbcinst.ini (where
> you put "unixODBC" which is a bit weird). In other words, the Driver line in
> my instructions assumes that the corresponding driver section is called
> "MySQL", but you called it "unixODBC". Also, it seems unusual to me that the
> "Setup = " line maps to unixodbc's libodbcinst.so instead of a myodbc .so
> file; my entry has "Setup=libodbcmyS.so"; that's on Debian GNU/Linux FWIW.
> 

Ok I made the change to MySQL, no help.

I don't have any libodbcmyS.so in /usr/lib64 or anywhere in this system.

Note that I haver never done this before, have no personal use for this and I'm only doing this for QA testing. I'm using an openSUSE VM specifically set up for testing this report.

> This sounds like LibreOffice is compiled for a different libodbc than what
> you have... Usually, when the .so has a different name, it means it is an
> incompatible version, and simply linking one to the other WILL NOT WORK (or
> can seem to work, but lead to crashes, data corruption, etc).

I'm using TDF's build:
Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7

I found this: http://www.unixodbc.org/
28.Nov.2011 	2.3.1 Released

Mainly bug fixes.
Major change is to change the library version number from 1 to 2 to signal the SQLLEN change for 64 land. Should have been done for 2.3.0, but better late than never. So if after installing you have apps that can't find libodbc.so, its likely they are linked to libodbc.so.1, so just create a symlink from libodbc.so.2 
----------

Based on that official suggestion to symlink, there seems to be no danger.

(In reply to Beluga from comment #41)
> (In reply to Lionel Elie Mamane from comment #40)

>> Also, it seems unusual to me that the
>> "Setup = " line maps to unixodbc's libodbcinst.so instead of a myodbc .so
>> file; my entry has "Setup=libodbcmyS.so"; that's on Debian GNU/Linux FWIW.

> I don't have any libodbcmyS.so in /usr/lib64 or anywhere in this system.

The name confused me... On my system libodbcmyS.so is part of unixodbc, not myodbc, so I was wrong, and this part of your setup is plausible.

>> This sounds like LibreOffice is compiled for a different libodbc than what
>> you have... Usually, when the .so has a different name, it means it is an
>> incompatible version, and simply linking one to the other WILL NOT WORK (or
>> can seem to work, but lead to crashes, data corruption, etc).

> I found this: http://www.unixodbc.org/
> 28.Nov.2011 	2.3.1 Released

> Mainly bug fixes.
> Major change is to change the library version number from 1 to 2 to signal
> the SQLLEN change for 64 land. Should have been done for 2.3.0, but better
> late than never. So if after installing you have apps that can't find
> libodbc.so, its likely they are linked to libodbc.so.1, so just create a
> symlink from libodbc.so.2 
> ----------
 
> Based on that official suggestion to symlink, there seems to be no danger.

OK. <shrug>

If I run odbcinst -q -d
I get:
[MySQL]

But if I run odbcinst -q -s
I get:
odbcinst: SQLGetPrivateProfileString failed with .

I tried to remedy this by putting in my .bashrc:
export LD_LIBRARY_PATH=/usr/lib64/unixODBC:/usr/lib64:
export ODBCSYSINI=/etc/unixODBC
export ODBCINI=/home/test/.odbc.ini

But it didn't help.

(In reply to Beluga from comment #43)
> If I run odbcinst -q -d
> I get:
> [MySQL]
> 
> But if I run odbcinst -q -s
> I get:
> odbcinst: SQLGetPrivateProfileString failed with .
> 
> I tried to remedy this by putting in my .bashrc:
> export LD_LIBRARY_PATH=/usr/lib64/unixODBC:/usr/lib64:
> export ODBCSYSINI=/etc/unixODBC
> export ODBCINI=/home/test/.odbc.ini
> 
> But it didn't help.

Just to be sure, have you relaunched bash afterwards?
Also, I found this link:
https://www.novell.com/products/linuxpackages/opensuse/unixodbc-devel.html which talks about "/usr/lib/unixODBC/libodbcmyS.la"
According to https://en.opensuse.org/openSUSE:Shared_library_packaging_policy, la files are "libtool config files".
Now I'm on Debian and don't know anything about these "la files".

(In reply to Julien Nabet from comment #44)
> (In reply to Beluga from comment #43)
> > If I run odbcinst -q -d
> > I get:
> > [MySQL]
> > 
> > But if I run odbcinst -q -s
> > I get:
> > odbcinst: SQLGetPrivateProfileString failed with .
> > 
> > I tried to remedy this by putting in my .bashrc:
> > export LD_LIBRARY_PATH=/usr/lib64/unixODBC:/usr/lib64:
> > export ODBCSYSINI=/etc/unixODBC
> > export ODBCINI=/home/test/.odbc.ini
> > 
> > But it didn't help.
> 
> Just to be sure, have you relaunched bash afterwards?

Yes, I logged out to be sure.

(In reply to Lionel Elie Mamane from comment #34)
> @vmiklos: as barely-discussed on IRC, this crash has only ever been
> reproduced on OpenSUSE,

If it's openSUSE-only, it sounds like we can't track this down w/bibisecting:
Whiteboard -> notBibisectable

Have had changes my system (see comment 2). Have tested the connection from Base to MariaDB with ODBC on OpenSUSE 13.2. LO couldn't connect to MariaDB through the mysql_odbc-connector OpenSUSE provided. I got the connection with the connector from the MySQL-homepage: mysql-connector-odbc-5.3.4-1.x86_64.rpm.

All seems to work well with this connector. No crash, input of data is possible. So I couldn't reproduce the bug any more. Works with every LO-Version. Have tested it with LO 4.0.5.2 and also with LO 4.3.6.2 on OpenSUSE 13.2 64bit rpm Linux.

Following last Robert's comment, what about putting this one as WFM (because it works with mysql odbc connector from mysql website), NOTOURBUG (because the mysql odbc driver provided by OpenSuse doesn't work so distrib pb not LO pb), other?

(In reply to Julien Nabet from comment #48)
> NOTOURBUG (because
> the mysql odbc driver provided by OpenSuse doesn't work so distrib pb not LO

The odbc-driver from OpenSUSE didn't connect to MaraiaDB at all - this is the buggy behavior there, because the driver didn't recognize the database as a version after MySQL 4.1.1.
Has nothing to do with this bug. The connection could be established in older versions - but LO crashed when using this connections.
All reported bugs are OpenSuse-related bugs. I would prefere WORKSFORME, but I haven't reported this bug and two other persons have recognized the same buggy behavior.

Just to inform I wrote a bug report in the bugzilla of openSUSE and gave them a link to this bug here. 
Hopefully soon the may solve the problem there.
Thanks to all guys who helped to solve this problem!

(In reply to Krasimir Ivanov from comment #50)
> Just to inform I wrote a bug report in the bugzilla of openSUSE and gave
> them a link to this bug here. 
> Hopefully soon the may solve the problem there.
> Thanks to all guys who helped to solve this problem!

Have done the same ...
https://bugzilla.opensuse.org/show_bug.cgi?id=921143

Think it would be a duplicate of yours.

Regards

Robert

Dear Robert,

I think it is better to have more bugs registered than no one.

Thank you for helping this way.

Migrating Whiteboard tags to Keywords: (notBibisectable)
[NinjaEdit]