f-spot crashes upon start when using older photos.db

[Harms]

Binary package hint: f-spot

After upgrading/moving from Fedora 4, where I had used F-Spot (briefly on one machine, extensively on another machine), to Ubuntu 6.10, F-Spot fails to start at all.

Steps to reproduce:
1. Just start F-Spot
What we would like to see: F-Spot should start.
What we actually end up seeing: F-Spot does not start.

Version: 0.2.1-1ubuntu (bundled with from Ubuntu 6.10)

I searched for this particular crasher bug. I found bugs about other crashes upon start, but not this one. Also, I realise that 0.2.1 is not up to date compared to upstream (and I do not know if this is fixed in upstream) -- however, I feel that this is a fairly egregious bug in an important and high-profile app that casual/non-expert users should not be exposed to.

When started on the command line, it gives the following error messages and stack traces:

Starting new FSpot server
XXXXX
Mono.Data.SqliteClient.SqliteSyntaxException: file is encrypted or is not a database
  at Mono.Data.SqliteClient.SqliteCommand.GetNextStatement (IntPtr pzStart, System.IntPtr pzTail, System.IntPtr pStmt) [0x00000]
  at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader (CommandBehavior behavior, Boolean want_results, System.Int32 rows_affected) [0x00000]
  at Mono.Data.SqliteClient.SqliteCommand.ExecuteNonQuery () [0x00000]
  at MetaStore.CreateTable () [0x00000]
  at MetaStore..ctor (Mono.Data.SqliteClient.SqliteConnection connection, Boolean is_new) [0x00000]
  at Db.Init (System.String path, Boolean create_if_missing) [0x00000]
  at FSpot.Core..ctor () [0x00000]
  at FSpot.Driver.Main (System.String[] args) [0x00000]
XXXXX
Starting new FSpot server
Starting new FSpot server
Starting new FSpot server

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Stacktrace:

  at (wrapper managed-to-native) System.Threading.Monitor.Monitor_try_enter (object,int) <0x00004>
  at (wrapper managed-to-native) System.Threading.Monitor.Monitor_try_enter (object,int) <0xffffffff>
  at System.Threading.Monitor.Enter (object) <0x00013>
  at (wrapper synchronized) DBus.Service.remove_SignalCalled (DBus.Service/SignalCalledHandler) <0xffffffff>
  at FSpot.Core.Proxy.Finalize () <0x00015>
  at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

 mono(mono_handle_native_sigsegv+0xde) [0x815644e]
 mono [0x8122c88]
 [0xffffe440]
 mono [0x80c3ab3]
 [0xb7419c11]
 [0xb7419b9c]
 [0xb4fc1d2c]
 [0xb4fc1cfe]
 [0xb4fc1c79]
 mono [0x80af103]
 mono [0x81158f1]
 mono [0x80af237]
 mono [0x80c6444]
 mono [0x810984e]
 mono [0x811fbf5]
 /lib/tls/i686/cmov/libpthread.so.0 [0xb7f08504]
 /lib/tls/i686/cmov/libc.so.6(__clone+0x5e) [0xb7e7651e]

[Harms (harms)]

I also experimented a little bit to be able to state with certainty that it is related to ~/.gnome2/f-spot/photos.db and not something else, e.g. ~/.gconf/apps/f-spot:

I briefly renamed the latter, and started f-spot, noting that it still crashed. I then briefly renamed the former, noting that f-spot now did not crash. (However, with an empty database the usefulness of f-spot is at this point all but absent, so I do not consider it a viable workaround.) After renaming the database back, the crash is reintroduced.

[Andrew Mitchell (ajmitch)]

Yes, it has already been filed (as bug 64323) and there are tips there on converting the database. Due to sqlite 2.x being in universe, it's not a simple matter of converting if the database format is old, and this only occurs when upgrading from old versions that were in universe, or from old releases of other distros.

[Harms (harms)]

Thank you.