GNOME Bugzilla – Bug 576418
crash in Glom: Just quit the applicatio...
Last modified: 2009-03-30 16:23:24 UTC
Version: 1.10.0 What were you doing when the application crashed? Just quit the application after creating a table in a new empty document. Seems to always crash on quit. Distribution: Fedora release 10.92 (Rawhide) Gnome Release: 2.25.92 2009-03-10 (Red Hat, Inc) BugBuddy Version: 2.25.91 System: Linux 2.6.29-0.258.rc8.git2.fc11.x86_64 #1 SMP Mon Mar 16 20:53:26 EDT 2009 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10600000 Selinux: Enforcing Accessibility: Disabled GTK+ Theme: Nodoka Icon Theme: Fedora GTK+ Modules: canberra-gtk-module, pk-gtk-module, gnomebreakpad Memory status: size: 423784448 vsize: 423784448 resident: 43163648 share: 26574848 rss: 43163648 rss_rlim: 18446744073709551615 CPU usage: start_time: 1237818082 rtime: 393 utime: 358 stime: 35 cutime:0 cstime: 3 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/glom' [Thread debugging using libthread_db enabled] [New Thread 0x7f2d9735c910 (LWP 31543)] [New Thread 0x7f2d998cd910 (LWP 31533)] 0x0000003150c0ea5d in waitpid () from /lib64/libpthread.so.0
+ Trace 213764
Thread 1 (Thread 0x7f2da0893800 (LWP 31531))
---- Critical and fatal warnings logged during execution ---- ** glibmm **: unhandled exception (type Glib::Error) in signal handler: domain: gda_statement_error code : 6 what : Wrong parameter type for 'next_value': expected type 'gchararray' and got 'GdaNumeric' ** glibmm **: unhandled exception (type Glib::Error) in signal handler: domain: gda_statement_error code : 6 what : Wrong parameter type for 'next_value': expected type 'gchararray' and got 'GdaNumeric' ** Gtk **: gtk_main_quit: assertion `main_loops != NULL' failed ----------- .xsession-errors --------------------- BaseDB::query_execute: ConnectionError: Wrong parameter type for 'next_value': expected type 'gchararray' and got 'GdaNumeric' (glom:31531): glibmm-CRITICAL **: unhandled exception (type Glib::Error) in signal handler: domain: gda_statement_error code : 6 what : Wrong parameter type for 'next_value': expected type 'gchararray' and got 'GdaNumeric' DEBUG: Base_DB::update_gda_metastore_for_table(): Calling Gda::Connection::update_meta_store_table() ... DEBUG: Base_DB::update_gda_metastore_for_table(): ... Finished calling Gda::Connection::update_meta_store_table() waiting for server to shut down.... done server stopped (glom:31531): Gtk-CRITICAL **: gtk_main_quit: assertion `main_loops != NULL' failed DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. --------------------------------------------------
Sorry, I can't reproduce it here in my jhbuild on Ubuntu Intrepid. This warning is very suspicious: " Wrong parameter type for 'next_value': expected type 'gchararray' and got 'GdaNumeric' " Do you definitely have the latest versions of libgda and libgdamm (and have you rebuilt glom with them)? Can you get a valgrind memcheck report for this, with --num-callers=30 or so?
Trying to reproduce this, now I keep running into an earlier bug (this time I'm running F-11 Beta on an external disk, not on a VM). Note that glom is compiled without sqlite support. libgda is 4.0, gdamm is 3.99.14. I keep running into an assertion violation at gda-connection.c:2987 : The call to gda_connection_get_meta_sore() returns NULL. Stepping through that call, it calls gda_meta_store_new() with a NULL argument (at line 4096), which itself, cnc-string being NULL, uses a SQLite:/ argument that looks suspicious to me since glom is compiled without sqlite support...
I have not seen that before. libgda use sqlite for its internal meta-store. I don't know if disabling the libgda sqlite (which also uses an internal copy of sqlite, not an external sqlite) breaks that. I hope not. Disabling sqlite support in Glom is good and should be unrelated.
Ok, so glom has a run-time dependency on libgda-sqlite which I wasn't aware of, so that addresses comment #2. You may want to consider adding a run-time check for this rather than a simple assertion. As for the crash-upon-exit bug, it seems to happen occasionally with other gnome apps as well, so it's unlikely to be glom-specific (although valgrind does how a number of invalid reads upon exit). I'll close this as not-a-bug.
I find that surprising. I am asking on gnome-db-list.
Was libgda built with an external sqlite? It should not be.
It may just be a packaging bug. The libgda package is split into multiple RPMs (to split the dependencies). The libgda-sqlite package contains only one file: /usr/lib/libgda-3.0/providers/libgda-sqlite.so If you temporarily remove it, that should trigger this assertion failure bug. > Was libgda built with an external sqlite? It should not be. No, there's nothing unusual in the way libgda is built, as far as I can tell.
On the mailing list, vivien says " I'm preparing a patch for the V4 and will release a 4.0.1 soon to make sure everything is OK even if the SQLite provider is not installed. " Let's remember to verify that.
This is fixed in libgda-4.0.1. Please make sure that your Glom package does not depend unnecessarily on the libgda-sqlite provider.