Oh nice :

Digikam::DatabaseCoreBackend::setDatabaseErrorHandler (this=0x0,
handler=0x14db760) at
/build/buildd/digikam2-2.1.1/core/libs/database/databasecorebackend.cpp:1624

==> this=0x0

Gilles caulier

Jose :

Look in the trace : 

#5  0x00007f8fcffb556c in ?? () from /usr/lib/nvidia-current/libGL.so.1

digiKam is not relvant of opengl ? You use a NVIDIA video card. Why i can see this trace in crash ?

Can you check if digiKam work fine in another coputer which don't use NVIDIA ?

Gilles Caulier

*** Bug 282097 has been marked as a duplicate of this bug. ***

2.1.1 is built from the 2.1.0 tag? Or any later revision?
Weird: line 1624 is end-of-file then.

Marcel,

yes, Nicolas has used 2.1.0 tag to build tarball.

I CC Nicolas for details.

Gilles Caulier

(In reply to comment #2)
> Jose :
> 
> Look in the trace : 
> 
> #5  0x00007f8fcffb556c in ?? () from /usr/lib/nvidia-current/libGL.so.1
> 
> digiKam is not relvant of opengl ? You use a NVIDIA video card. Why i can see
> this trace in crash ?
> 
> Can you check if digiKam work fine in another coputer which don't use NVIDIA ?
> 
> Gilles Caulier

Yes I use a Nvidia card with drivers propietary

I have what appears to be the same problem on Ubuntu 11.04 x86_64 with Intel graphics.  Installed a couple of days ago from philip5 ppa. Worked well until updated to 2.1.1 last night.  Now segfaults every time.  Backtrace below.

Dave Stevenson

Application: digiKam (digikam), signal: Segmentation fault
[Current thread is 1 (Thread 0x7f09403eda20 (LWP 11590))]

Thread 4 (Thread 0x7f09219f1700 (LWP 11591)):
#0  0x00007f093788ff03 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f0931f4d104 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f0931f4d9f2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f09270b6c44 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007f0931f743e4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f093759fd8c in start_thread (arg=0x7f09219f1700) at pthread_create.c:304
#6  0x00007f093789d04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7f09142e8700 (LWP 11593)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f09388c382b in wait (this=<value optimized out>, mutex=0x1e8bbb8, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:88
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x1e8bbb8, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:160
#3  0x00000000005bbd30 in Digikam::ScanController::run (this=0x1e85220) at /build/buildd/digikam2-2.1.1/core/digikam/database/scancontroller.cpp:647
#4  0x00007f09388c3175 in QThreadPrivate::start (arg=0x1e85220) at thread/qthread_unix.cpp:320
#5  0x00007f093759fd8c in start_thread (arg=0x7f09142e8700) at pthread_create.c:304
#6  0x00007f093789d04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f0913ae7700 (LWP 11594)):
#0  0x00007f093788ff03 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f0931f4d104 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f0931f4d639 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f09389d5446 in QEventDispatcherGlib::processEvents (this=0x1e90ad0, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:424
#4  0x00007f09389a9882 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149
#5  0x00007f09389a9abc in QEventLoop::exec (this=0x7f0913ae6b30, flags=...) at kernel/qeventloop.cpp:201
#6  0x00007f09388c0924 in QThread::exec (this=<value optimized out>) at thread/qthread.cpp:492
#7  0x00007f093898bc2f in QInotifyFileSystemWatcherEngine::run (this=0x1e8f7a0) at io/qfilesystemwatcher_inotify.cpp:248
#8  0x00007f09388c3175 in QThreadPrivate::start (arg=0x1e8f7a0) at thread/qthread_unix.cpp:320
#9  0x00007f093759fd8c in start_thread (arg=0x7f0913ae7700) at pthread_create.c:304
#10 0x00007f093789d04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f09403eda20 (LWP 11590)):
[KCrash Handler]
#6  Digikam::DatabaseCoreBackend::setDatabaseErrorHandler (this=0x0, handler=0x1e984b0) at /build/buildd/digikam2-2.1.1/core/libs/database/databasecorebackend.cpp:1624
#7  0x000000000059153a in Digikam::AlbumManager::setDatabase (this=0x1e7aa50, params=..., priority=<value optimized out>, suggestedAlbumRoot=...) at /build/buildd/digikam2-2.1.1/core/digikam/album/albummanager.cpp:726
#8  0x000000000068b9ac in main (argc=1, argv=0x7fffb6b6f2e8) at /build/buildd/digikam2-2.1.1/core/digikam/main/main.cpp:185

Please compare bug 281767 Comment #13 :(

Can someone start digikam under gdb and compare if the same backtrace results? Line 1624 is the last line of the file, the '}' closing the namespace, so the backtrace is somehow broken.

See http://www.digikam.org/drupal/contrib how to run digikam under gdb. Even better, with current git.

OS: ArchLinux
Qt: 4.7.4
KDE: 4.7.1
Intel video drivers

It seems I have the same bug -- both 2.1.1 and 2.2.0 digikam crash at the startup in Digikam::DatabaseCoreBackend::setDatabaseErrorHandler() (sorry, no debug symbols at hand to provide stacktrace).
If that helps -- I started using digikam directly from 2.1.0. Downgrading to 2.1.0 helps -- digikam starts normally and my photo db seems to be ok.

It seems, my problem was in incompatible config/digikamrc file.
Somehow, when I started using digikam 2.1.0, it created a file with [Database Settings] section, where there were two sets of database options: Images XXX=... and Thumbnails XXX=...
I figured out that digikam 2.1.1+ expects options named like Database XXX=... instead.

So, essentially, digikam 2.1.1+ failed to read my 2.1.0 db config properly -- and in the debug I see DatabaseParameters contains default empty values that causes crash somewhere later in setErrorHandler(), because this=0.

I hope now you can reproduce that. It would be nice to gracefully handle missing/wrong db parameters situation.

Alexey: can you attach such a broken config file?

*** Bug 283480 has been marked as a duplicate of this bug. ***

Created attachment 64322 [details]
digikamrc config from 2.1.0 that causes 2.1.1+ crash

My original config file was already fixed, so I had to reproduce: deleted current config, downgraded to 2.1.0, completed initial wizard, exited, backed up digikamrc, upgraded back to 2.2.0 -> it crashes.

Created attachment 64421 [details]
New crash information added by DrKonqi

digikam (2.2.0) on KDE Platform 4.7.2 (4.7.2) using Qt 4.7.4

- What I was doing when the application crashed:

Trying to open digikam 2.2.0 and i can't do it, tried also deleting digikam.db but it didn't help

-- Backtrace (Reduced):
#6  Digikam::DatabaseCoreBackend::setDatabaseErrorHandler (this=0x0, handler=0xf01c40) at /build/buildd/digikam-2.2.0/core/libs/database/databasecorebackend.cpp:1624
#7  0x000000000059c698 in Digikam::AlbumManager::setDatabase (this=0xf51430, params=..., priority=<optimized out>, suggestedAlbumRoot=...) at /build/buildd/digikam-2.2.0/core/digikam/album/albummanager.cpp:728
#8  0x00000000004896ca in main (argc=1, argv=<optimized out>) at /build/buildd/digikam-2.2.0/core/digikam/main/main.cpp:185

Removing $HOME/.kde/share/apps/digikam and $HOME/.kde/share/config/digikamrc solves the issue for me

I tried any combinations with current git (only "Database" only "Images/Thumbnails", both) but it just worked and did not crash.
Can someone confirm it's indeed the [Database Settings] section causing trouble?
Or was something fixed in the meantime?

digiKam 2.2.0 is out since few weeks. Crash still valid with this version ?

Gilles Caulier

@Gilles Caulier
> digiKam 2.2.0 is out since few weeks. Crash still valid with this version ?
2.2.0 crashes for me, see comments #11, #12, #15.
Don't know if the trunk version crashes.

Alexey,

It still valid with digiKam 2.4 ?

Gilles Caulier

@Gilles
I'm not able to test -- compilation of 2.4.x and 2.5.0 fails, because my system runs boost 1.48 and I'm affected by https://bugs.kde.org/show_bug.cgi?id=287772

Ok, so with the patches from my repo I was able to compile 2.5.0 and test this bug.
When I use digikamrc from the attachment, digikam doesn't crash, it shows the dialogbox 'Error while opening the database. digiKam will try to automatically reconnect to the database' with progress bar which goes on forever. On the console the following is being written:

digikam(25501)/digikam (core): Please set parameters before setting a database error handler 
QSqlDatabase:  driver not loaded
QSqlDatabase: available drivers: QSQLITE QSQLITE3 QMYSQL3 QMYSQL QODBC3 QODBC QPSQL7 QPSQL
digikam(25501)/digikam (core): Error while opening the database. Error details [ QSqlError(-1, "Driver not loaded", "Driver not loaded") ] 

The last line is being repeated multiple time.

If 'Cancel' is pressed in the dialog box, there's an error box about no working database. When I press OK, the digikam crashes:

Thread 1 (Thread 0x7f705d36c980 (LWP 25501)):
[KCrash Handler]
#6  0x00007f705ab741e0 in Digikam::DatabaseCoreBackend::status() const () from /usr/lib/libdigikamcore.so.2
#7  0x00007f705a500427 in Digikam::DatabaseAccess::DatabaseAccess() () from /usr/lib/libdigikamdatabase.so.2
#8  0x00007f705a4e8d60 in Digikam::CollectionScanner::databaseInitialScanDone() () from /usr/lib/libdigikamdatabase.so.2
#9  0x00000000005c67fb in ?? ()
#10 0x000000000058b32b in ?? ()
#11 0x000000000048b907 in ?? ()
#12 0x00007f70568e838d in __libc_start_main () from /lib/libc.so.6
#13 0x000000000048d375 in _start ()

Overall, it's better than it was before as digikam reports the source of the problem, but maybe more graceful handling of incorrect data in .ini file is still required.

Official digiKam 2.6.0 release is out since few days now :

http://www.digikam.org/drupal/node/656

Please, check if this entry still valid, or update report accordingly.

Thanks in advance.

Gilles Caulier

New digiKam 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

Gilles caulier

I have no issues like this with the recent digikam versions  for quite a while. I don't know, though, whether that's because the potential crash was fixed or digikamrc was always in sync with the recent digikam.