| Summary: | MYSQL : settings and installation wizard freeze when valid mariadb/mysql db connection is available [patch] | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Christian <buitk14> |
| Component: | Database-Mysql | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | grave | CC: | b-misc, beaaeecffmiqwryxcmbw2ta2cukc4, caulier.gilles, david.varnes, freisim93, fsalvert, kde.bugs, mail, meensb, montex, opensource, otherland, tom, vdmjpr |
| Priority: | NOR | ||
| Version: | 4.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/digikam/f0400ec7e518e753e0c4ccab4eb2b8b022f91767 | Version Fixed In: | 4.5.0 |
| Sentry Crash Report: | |||
| Attachments: |
after first setup open settings for "Database" - works
once mysql connection is available the setting windows freezes: eg. collection bt for suse 13.1 with dk 4.1.0 build 11.1 - at the time the windows freezes reproduce bug: working kde settings for digikam (no mysql db) reproduce bug: kde settings for digikam with mysql db: settings freeze quick'n'dirty hack to prevent freeze when using mysql db backend digikam-libs |
||
|
Description
Christian
2014-07-23 18:41:02 UTC
Created attachment 87908 [details]
after first setup open settings for "Database" - works
Created attachment 87909 [details]
once mysql connection is available the setting windows freezes: eg. collection
Created attachment 87910 [details]
bt for suse 13.1 with dk 4.1.0 build 11.1 - at the time the windows freezes
Created attachment 87911 [details]
reproduce bug: working kde settings for digikam (no mysql db)
rename this to digikamrc in your kde4 settings folder
Created attachment 87912 [details]
reproduce bug: kde settings for digikam with mysql db: settings freeze
rename this to digikamrc in your kde4 settings folder
I experience the exact same problems under debian testing. Since the upgrade to 4.1.0 came in, entering settings window causes freeze when using mysql. Using sqlite Database there is no such problem. Same here, Debian Testing, digikam 4.1 Additional note: I used the setup digikam + mySQL for about a year now, on an older machine, also Debian Testing, and up to digikam 4.0 without this problem. Have there be changes to the mySQL support of digikam? (I just found out that there is a GSoC project planned for next summer.) No. Nothing has changed about MySQL support. There is no code change since a while about this feature. Perhaps the distro switch from MySQL to MariaDB has introduced some side effects... Gilles Caulier (In reply to Gilles Caulier from comment #9) .. > Perhaps the distro switch from MySQL to MariaDB has introduced some side > effects... > > Gilles Caulier Yes, I have similar experience with openSuse 11.x + digikam 3.2: there was no freeze. With openSuse 12.x + digikam 3.5 the freeze started (I did not recognize the bug that time. thought its just a crash). With openSuse 12.x mysql was replaced by mariadb. The maria db core is almost identical with mysql server. There were no issues in my java and php projects. Possible reasons: - It might be related to some specific queries that were optimized for old mysql tables or system tables. - Latest maria and mysql packages have different default settings compared to the ones a couple of years ago, e.g. inno-db tables (no isam), different tablespaces, worker and memory settings and improved security model. - mix of old qt4 libs and new mysql libs to access the db - hopefully it is not something like this I will invest a little time next week to log what is going on in the db before the freeze occurs. Christian I also experience a freezing of the setting windows after some seconds on ubuntu, using the mysql database Application: digikam (4.2.0) KDE Platform Version: 4.13.3 Qt Version: 4.8.6 Operating System: Linux 3.13.0-34-generic x86_64 Distribution: Ubuntu 14.04.1 LTS I also tried to reproduce the error on ubuntu with a fresh installation of digikam 4.2.0. After the installation the settings menu works. Then I create a mysql-database, and change the database settings to mysql. Then I open the settings menu, and get the freeze. Since I have mysql, no mariadb, the freeze seems not to be related to mariadb. Here my packages: digikam:amd64/trusty 4:4.2.0-trusty~ppa1 uptodate digikam-data:all/trusty 4:4.2.0-trusty~ppa1 uptodate libkface-data:all/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libkface2:amd64/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libkgeomap-data:all/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libkgeomap1:amd64/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libkvkontakte1:amd64/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libmediawiki1:amd64/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate akonadi-backend-mysql:all/trusty-updates 1.12.1-0ubuntu1.1 uptodate libdbd-mysql-perl:amd64/trusty 4.025-1 uptodate libmysqlclient18:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate libqt4-sql-mysql:amd64/trusty 4:4.8.5+git192-g085f851+dfsg-2ubuntu4 uptodate mysql-client:all/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-client-5.5:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-client-core-5.5:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-common:all/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-server:all/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-server-5.5:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-server-core-5.5:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate php5-mysql:amd64/trusty-security 5.5.9+dfsg-1ubuntu4.3 uptodate I hit this bug on Gentoo with MySQL 5.6.20 and digiKam 4.2.0. If there is a way I can help with debugging please ask. Same here on Fedora 20. I haven't changed any settings lately so I cannot tell exactly with which version the issue came up. digikam-4.2.0-5.fc20.x86_64 digikam-doc-4.2.0-5.fc20.noarch digikam-libs-4.2.0-5.fc20.x86_64 mariadb-5.5.39-1.fc20.x86_64 mariadb-libs-5.5.39-1.fc20.x86_64 mariadb-server-5.5.39-1.fc20.x86_64 Seems the dbms doesn't even need to be available to freeze digikam. I stopped the mysql/mariadb daemon, started digikam, enterted the configuration dialog and it froze... I don't have experience in the field but I tried to debug. Unfortunately almost no tool shows any information when the bug occurs. I build digikam with debug information and tried gdb, strace, ltrace, xsession-errors and to enable console debug output from kdedebugdialog. The only thing I could get was a ltrace. I started ltrace after digikam started using 100% CPU. I captured for 30 seconds. As you can see it kept one core busy for all these seconds. I don't know much about debugging, if there is something more I can do please ask. $ ltrace -c -p 1543 % time seconds usecs/call calls function ------ ----------- ----------- --------- -------------------- 25.07 14.428802 2932 4921 _ZN9KLineEdit7setTextERK7QString 13.49 7.765201 3156 2460 _ZN13KUrlRequester6setUrlERK4KUrl 13.35 7.686855 3123 2461 _ZN13KUrlRequester7setTextERK7QString 11.47 6.600541 191 34454 _ZNK9KLineEdit10metaObjectEv 5.19 2.988895 607 4922 _ZN6QTimer10singleShotEiP7QObjectPKc 5.07 2.917442 395 7383 _ZN7QObject5eventEP6QEvent 2.56 1.471184 199 7383 _ZNK11QMetaObject4castEP7QObject 2.46 1.414286 191 7383 _ZN4KUrlD1Ev 2.42 1.393034 188 7383 _ZN7QObject10childEventEP11QChildEvent 1.74 0.999831 203 4922 _ZNK13KUrlRequester3urlEv 1.64 0.942333 191 4922 memcpy 1.63 0.940316 191 4922 _ZN4QDirC1ERK7QString 1.63 0.939874 190 4922 _ZN4QDirD1Ev 1.63 0.939664 190 4922 _ZN7QWidget10setVisibleEb 1.63 0.937098 190 4922 _Z13qFlagLocationPKc 1.63 0.937079 190 4922 _ZN7QString4freeEPNS_4DataE 0.83 0.476242 193 2461 _ZN4QDir8homePathEv 0.83 0.475179 193 2461 _ZN4KUrlC1ERK7QString 0.82 0.474374 192 2461 _ZNK4KUrl11toLocalFileENS_16AdjustPathOptionE 0.82 0.473673 192 2461 _ZN4QDir20fromNativeSeparatorsERK7QString 0.82 0.473577 192 2461 _ZN4QDir14isRelativePathERK7QString 0.82 0.473350 192 2461 _ZNK13KUrlRequester4textEv 0.82 0.473245 192 2461 _ZN4QDir18toNativeSeparatorsERK7QString 0.82 0.471372 191 2461 _ZN7QStringC1EiN2Qt14InitializationE 0.82 0.470804 191 2461 _ZNK4KUrl4pathENS_16AdjustPathOptionE ------ ----------- ----------- --------- -------------------- 100.00 57.564251 135353 total strace during freeze just gave many lines likes this: brk(0xeedc000) = 0xeedc000 brk(0xeefd000) = 0xeefd000 brk(0xef1e000) = 0xef1e000 brk(0xef3f000) = 0xef3f000 brk(0xef60000) = 0xef60000 brk(0xef81000) = 0xef81000 brk(0xefa2000) = 0xefa2000 brk(0xefc3000) = 0xefc3000 brk(0xefe4000) = 0xefe4000 Confirming this with Digikam 4.3.0 under Xubuntu. After opening settings the Digikam process takes 100% cpu, as if stuck in infinite loop? *** This bug has been confirmed by popular vote. *** Yes, I can confirm this too in Debian sid, Digikam 4.3.0. I also tried to stop the MySQL daemon, but the configuration page still freezes even if the database is not reachable. I must say I am reliefed from finding this bug report, I thought my settings were messed in some way.... I can also confirm this bug: Fedora 20 digikam-libs-4.3.0-2.fc20.x86_64 digikam-4.3.0-2.fc20.x86_64 mariadb-devel-5.5.39-1.fc20.x86_64 mariadb-embedded-5.5.39-1.fc20.x86_64 mariadb-5.5.39-1.fc20.x86_64 mariadb-server-5.5.39-1.fc20.x86_64 mariadb-libs-5.5.39-1.fc20.x86_64 Following config also suffers from this bug: Linux Mint 17 / KDE digikam 4:4.3.0-trusty~ppa1 digikam-data 4:4.3.0-trusty~ppa1 kipi-plugins-common 4:4.3.0-trusty~ppa1 libkdcraw23 4:4.13.0-0ubuntu1 libkipi11 4:4.13.0-0ubuntu1 libkipi-data 4:4.13.0-0ubuntu1 kipi-plugins 4:4.3.0-trusty~ppa1 with the wokring MySQL database running on a QNAP NAS. When going to settings menu --> database migration, I experience exact the same behaviour, eg digikam eating 100% cpu after a few seconds, even when the DB connection is not available (and digikam correctly presents a error message during startup). Created attachment 89156 [details]
quick'n'dirty hack to prevent freeze when using mysql db backend
The reported freezing seems to be related to the delayed checking of the database file path which is unused for external DB server connections. Somehow that code runs amok and causes 100% load on one cpu core - I didn't have the time to investigate the real reason behind that behavior. In the attached patch I've just moved both connect() calls of that file path input field to a "later" code position and made it conditional based on type of DB backend. Sorry but how to you add such patch ? Really missing MYSQL with Digikam. (In reply to fsalvert@gmail.com from comment #24) > Sorry but how to you add such patch ? Really missing MYSQL with Digikam. ...uuuhm - I just hope we talk about the same thing here: that patch is only "useful" if you have the digikam source code at hand and know how to (re-)build it from scratch. My assumption is, that if you know how to compile the source tree, you should also know how to apply patch files to your working copy - sorry, but it's not a "end-user-friendly" solution to the problem ;) Tom, you guessed me right. I'm not building Digikam from source and was hoping this would be easier to apply. Hope they incorporate your patch to rpms or I might just learn how to build from source :-) Git commit f0400ec7e518e753e0c4ccab4eb2b8b022f91767 by Gilles Caulier. Committed on 28/10/2014 at 14:58. Pushed by cgilles into branch 'master'. apply patch #89156 FIXED-IN: 4.5.0 M +2 -1 NEWS M +19 -16 libs/widgets/common/databasewidget.cpp http://commits.kde.org/digikam/f0400ec7e518e753e0c4ccab4eb2b8b022f91767 Thank you for fixing this bug. I will try the patch as soon as possible :) @fsalvert: if you are using some pacakge-based distribution, you may try to look at guides for creating patched packages. Something exists for debian, for example. It may be easier than rebuilding all from source, but still some advanced knowledge and skills are required. Thank you Gillles for you patch. I'am using fedora 20, 64 bits version. I have downloaded 4.4.0 digikam version from fedora updates repository. I have only replaced databasewidget.cpp by new version and recreated a new rpm with 'rpmbuild -ba' I can now use Digikam 4.4.0 configuration to add a new collection. Before , after each "yum update" , I was replacing current digikam version with 3.5.0 version from fedora releases repository. Jean-Pierre, can you post your final rpm ? Will try it out on openSuse. Thanks Created attachment 89378 [details]
digikam-libs
It's named 4.4.2-9 to be sure that next version from fedora without that patch will not remove my version but, in fact it is the 4.4.0 with Gilles caulier patch.
Thanks...openSuse does not seem to use this package digikam-libs normally. Will try it anyways and see if it works :-) I do'nt have checked where the patch goes. but you need 2 packages in fedora: digikam and digikam-libs , but the package digikam is too big to be posted directly here. I can provide access to my ftp server, if you want to have acces to anything generated. Hi, Just to post out there that SQL is fixed in openSuse with Digikam version 4.4.0-28.1. Great ! Thanks I can confirm that the patch works on digikam 4.4. I tried it on the current Debian sid version, which is 4.4.0-1. I created patched debian packages for me, but maybe they can be useful to someone else (only amd64 architecture): https://www.dropbox.com/sh/xo6vshks7ehtvzi/AAANiZxu2TtK8fz3_UyZyp_wa?dl=0 |