Bug 658471

Created attachment 463787 [details]
crappy looking patch fixing sqlite3 loading

Hi Haïkel,

I'm not sure that your change is going to fix this issue.

The problem isn't that the first check is failing and then bailing out - the code is doing the correct thing here - it's the fact that *all 3* checks are failing to find the library.

I guess the question that needs resolved what is g_module_open() doing to find shared libs? And why it's failing?

There's also the question of what's the SEARCH_LIB_PATH - is that passed to ./configure? Has it correctly set for X86_64 builds? Which was my first thought.

BTW. Normally on my system LD_LIBRARY_PATH is not set, and that's never been a problem until now.

Cheers,

> There's also the question of what's the SEARCH_LIB_PATH
it's a compile time defined macro,
from libgda/sqlite/Makefile.am line 66:
libgda_sqlite_la_CFLAGS = -DPNAME=\""SQLite"\" -DCLASS_PREFIX=\""GdaSqlite"\" -DSEARCH_LIB_PATH=\""$(SQLITE_PATH)"\"

During configure, SQLITE_PATH is properly set to "/usr/lib64" on x86_64 so it has nothing to do with this issue.
------------------------------------------

The patch above do fix that issue, i'll tell you why.

I ran both Glom and Anjuta under GDB and each time, each time, it fails at loading symbol "sqlite3_column_database_name" in load_symbols from libgda/sqlite/gda-symbols-util.c
(gdb) call g_module_error()
(gdb) p (char *)$1
0xcddc80 "`sqlite3_column_database_name': /usr/lib64/xulrunner-1.9.2/libsqlite3.so: undefined symbol: sqlite3_column_database_name"

The matter is that g_module_open tries to load the *WRONG* libsqlite3 from xulrunner which may have some missing symbols from upstream sqlite3.
So, the first check succeeds by loading the module and symbol "sqlite3_open" and when load_symbols is called later, it fails so the s3r pointer is freed ===> failure.
The latter checks calls "find_sqlite_in_dir" which restrict the path where searching the modules so they load the right libsqlite3. That explains why my patch works.

Let me explain, why your workaround did work:
g_module_open internally calls dlopen which follows this search path:
1. LD_LIBRARY_PATH which is empty on vanilla install
2. /etc/ld.so.cache
an excerpt from my local cache:
/usr/lib64/xulrunner-1.9.2/libsqlite3.so^@libsqlite3.so^@/usr/lib64/libsqlite3.so

By setting LD_LIBRARY_PATH, you were just bypassing the linker cache.

For testing purpose:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2635940

I have the same problem with anjuta in x86. With the new rpm of libgda and libgda-sqlite all works OK. Thanks :)

libgda-4.2.2-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/libgda-4.2.2-1.fc14

libgda-4.2.2-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libgda'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/libgda-4.2.2-1.fc14

Even after updating to this update from updates-testing I can reproduce the problem:
[rakesh@localhost ~]$ rpm -q anjuta libgda
anjuta-2.32.1.0-1.fc14.x86_64
libgda-4.2.2-1.fc14.x86_64

Anjuta I pulled the recent build from koji not even yet in updates-testing. But I think I can re-test it with what is in stable if you want me to.

[rakesh@localhost ~]$ anjuta

** (anjuta:2642): WARNING **: Can't find libsqlite3.so file.

(anjuta:2642): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

(anjuta:2642): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

** (anjuta:2642): WARNING **: Can't find libsqlite3.so file.

(anjuta:2642): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

** (anjuta:2642): WARNING **: Can't find libsqlite3.so file.

(anjuta:2642): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

(anjuta:2642): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

** (anjuta:2642): CRITICAL **: gda_server_provider_supports_feature: assertion `GDA_IS_SERVER_PROVIDER (provider)' failed

** (anjuta:2642): WARNING **: Can't find libsqlite3.so file.

(anjuta:2642): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

(anjuta:2642): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(anjuta:2642): libanjuta-symbol-db-WARNING **: Could not open connection to DB_DIR=/home/rakesh/.cache/anjuta;DB_NAME=.anjuta_sym_db


libanjuta-symbol-db-ERROR **: Opening global project under /home/rakesh/.cache/anjuta
aborting...

Between I am not using LD_LIBRARY_PATH to overwrite linker rules.

I used the update to libgda and reinstalled anjuta and I still get the same error that everyone else is getting.

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

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

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

IMHO this issue has nothing to do with libgda itself but with a wrong oder of library paths in Fedora. Why do the firefox/xulrunner libraries come before the system installation path?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Start Anjuta
2. Crash



Comment
-----
Tried to start Anjuta. My /home direcory was NOT formatted for Fedora 14 re-installation so the config files were left untouched from the old F14 install. However, once I got the first crashes, I manually removes ~/.cache ~/.config/anjuta and ~/.gconf/apps/anjuta - it did not help so I'm filing this bug. Anjuta was working fine in a previous F14 installation - the only reason I re-installed F14 was because I migrated to SSD drive (while preserving /home)

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Installed using yum in fc14
2. Tried to run
3. Don't know what else...

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I did some more investigation:

/etc/ld.so.conf/xulrunner-64.conf sets LD_LIBRARY_PATH to /usr/lib64/xulrunner-1.9.2 which contains libsqlite3.so.

On my system there is
-rwxr-xr-x. 1 root root 599248 19. Apr 2010  /usr/lib64/libsqlite3.so.0.8.6
and
-rwxr-xr-x. 1 root root 588456  9. Dez 13:55 /usr/lib64/xulrunner-1.9.2/libsqlite3.so

libgda seems to pick exactly the wrong one presumely because the xulrunner one appears first in LD_LIBRARY_PATH. I don't think libgda is wrong in asumming that g_module_open finds the correct library it was build against.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #17)
> I did some more investigation:
> 
> /etc/ld.so.conf/xulrunner-64.conf sets LD_LIBRARY_PATH to
> /usr/lib64/xulrunner-1.9.2 which contains libsqlite3.so.
> 
> On my system there is
> -rwxr-xr-x. 1 root root 599248 19. Apr 2010  /usr/lib64/libsqlite3.so.0.8.6
> and
> -rwxr-xr-x. 1 root root 588456  9. Dez 13:55
> /usr/lib64/xulrunner-1.9.2/libsqlite3.so
> 
> libgda seems to pick exactly the wrong one presumely because the xulrunner one
> appears first in LD_LIBRARY_PATH. I don't think libgda is wrong in asumming
> that g_module_open finds the correct library it was build against.
> 
> 
> 
> -- 
> Fedora Bugzappers volunteer triage team
> https://fedoraproject.org/wiki/BugZappers

Has everybody confirmed that the patch submitted by Haïkel Guémar (see above) still does not work for them?

If this patch still does not work (I haven't had time to check it myself) then can I suggest another change to the code of libgda ?
file: libgda-4.2.2/libgda/sqlite/gda-symbols-util.c
function: find_sqlite_library  (<--source of the error)
line: 123

Change the order of checks to use the compile time SEARCH_LIB_PATH *first* 
If this var is set to (e.g. /usr/lib64/) at compile time, then this will 
always look in the right place first, and ignore what's in the ld.so cache.

The patch by Haïkel Guémar effectively skips the whole dlopen call, and goes straight to using the LD_LIBRARY_PATH, but if anybody has set this then they could still get the wrong sqlite3.so loaded, so I recommend going straight to the compile time var first, then trying dlopen.

The problem here unfortunately appears to be an example of DLL hell, where there are multiple copies of the same dll in different locations shipped by xulrunner and thunderbird. You can see this by :
  lsof | grep libsqlite3

Hi!

> Has everybody confirmed that the patch submitted by Haïkel Guémar (see above)
> still does not work for them?

Various people reported that it doesn't work for them with the libgda-update.

> If this patch still does not work (I haven't had time to check it myself) then
> can I suggest another change to the code of libgda ?
> file: libgda-4.2.2/libgda/sqlite/gda-symbols-util.c
> function: find_sqlite_library  (<--source of the error)
> line: 123
> 
> Change the order of checks to use the compile time SEARCH_LIB_PATH *first* 
> If this var is set to (e.g. /usr/lib64/) at compile time, then this will 
> always look in the right place first, and ignore what's in the ld.so cache.

That looks reasonable to me. The compile time directory *should* always be the correct one.
 
> The problem here unfortunately appears to be an example of DLL hell, where
> there are multiple copies of the same dll in different locations shipped by
> xulrunner and thunderbird. You can see this by :
>   lsof | grep libsqlite3

The proper solution would be to either
* rename firefox's libsqlite3 to something like libsqlite3-mozilla
* make firefox just use the system library but I guess mozilla is very special here

Anyway, as I don't think one of these solutions will make it in as a stable update, a new patch would be welcome. For f15 we might consider something else though.

Thanks!





-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I changed my patch according ardee's advice, here's a scratch build for testing purpose:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2663475
I'm not found of overriding the LD_LIBRARY_PATH search method since it may have legitimate use (for instance, using a custom sqlite3 shared library + extensions like sqlite virtual tables). 

From what i remember, xulrunner ships vanilla sqlite3 sources but uses different compilation flags suited to their needs. I'm not sure that using system sqlite3 is a short or even medium term solution for them.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1.install anjuta anjuta-devel from yum repositories
2.run anjuta
3.programm abort

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. start anjuta (panel|menu|console)
2. crash

Note: running it from console says it misses libsqlit3.so which is part of xulrunner-1.9.2.13-1.fc14.i686 BUT why does the 64bit version (which I have installed not satisfy this dependency?

So either it is a bug of the rpm package just miising the dependency or anjuta is flawed requireing a i686 version of xulrunner though its running on x86_64 OS/System

** (anjuta:3702): WARNING **: Can't find libsqlite3.so file.
(anjuta:3702): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed
(anjuta:3702): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed


Comment
-----
Fresh install of fedora1 14 x86_64, update all packages,  install anjuta

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Launch Anjuta.

Comment
-----
I tried launching Anjuta after installation to a freshly installed F14 (which had been updated and rebooted).

The package from update testing does NOT fix the issue

Since i'm out of options, i'll CC xulrunner maintainers and kindly ask them to fix that issue.
To summarize:
xulrunner's libsqlite3 shared library appears before mainstream's libsqlite3 in linker cache which breaks libgda by loading a "crippled" libsqlite3 which in turns prevents Anjuta from launching.

Nirik kindly pointed me out this ticket:
https://fedorahosted.org/fpc/ticket/34

The fact is that xulrunner ships libsqlite3.so which overrides any other *.so.*
The solution is as simple as to create a symlink:

ln -s /usr/lib64/libsqlite3.so.0.8.6 /usr/lib64/libsqlite3.so

You may prefer to install sqlite-devel (which ships that symlink) to avoid conflicts.

I can confirm that the solution installing sqlite-devel from coment 26 works perfectly

Installing sqlite-devel did not fix it for me.

I can confirm that the solution installing sqlite-devel from coment 26 works perfectly

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Start Anjuta (crashes immediately)
2.
3.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. the program crashed as it is started
2.
3.


Comment
-----
I just try to start the program and it immeidately crashed

I can confirm that installing sqlite-devel as suggested in comment 26 works, but only if the libgda and libgda-sqlite versions from updates-testing are also installed, as suggested in comment 7.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. installed pre-requisites for Anjuta
2. installed anjuta
3. ran anjuta

I confirm that updating libgda from updates-testing and installing sqlite-devel solves the issue.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1.I just clicked on the Anjuta icon
2.
3.


Comment
-----
No indications, just the crash

Updating libgda from testing and installing sqlite-devel solves this issue.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. start anjuta - crash right during splash screen

Confirmed:
su -c 'yum -y --enablerepo=updates-testing update libgda'

solves the problem here as well with the following files:
libgda-4.2.2-1.fc14.x86_64.rpm
libgda-sqlite-4.2.2-1.fc14.x86_64.rpm

thanks!

I'll check if we can rename the xulrunner sqlite3 library.

Please check xulrunner-1.9.2.13-2.fc14.

xulrunner-1.9.2.13-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/xulrunner-1.9.2.13-2.fc14

@Martin Stranky: it does solve the issue at least for me. Thank you !
@everyone: please downgrade to stable's libgda before testing the latest xulrunner in updates-testing. If there's no negative feedbacks, i'll submit a libgda update without any whacky patch.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. start anjuta
2.
3.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1.Applications
2.Programming
3.Anjunta


Comment
-----
Just attempt to launch the program after a major update on 12-2010..

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1.Install anjuta
2.run anjuta with `$ anjuta`
3.see a bit of the splash screen before it fails

Note that in Fedora 15 (xulrunner 2), it's called "libmozsqlite3.so", so it won't conflict anymore.

However, removing the ld.so.conf.d file breaks the case where a program (gnome-shell) is consuming a library (gjs) which itself consumes libmozjs.so, because e.g. /usr/lib/xulrunner-2 is no longer on the run path.

I think though I am going to change gnome-shell to use an ELF binary with RPATH set.  But I'm commenting on this bug so other xulrunner consumers know that they probably need to change.

I just ran into the gnome-shell issue. I think pushing an update which breaks gnome-shell is probably not a good idea; can we hold this update until gnome-shell is fixed?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Perhaps an update renaming the file would work for f14? Removing the ld.so.conf.d file is certainly the best long-term solution but I am not sure if this is save in a stable version.

(In reply to comment #46)
> I think though I am going to change gnome-shell to use an ELF binary with RPATH
> set.  But I'm commenting on this bug so other xulrunner consumers know that
> they probably need to change.

Please do that change for rawhide. We're going to keep it in testing for F14 so it should not affect common Fedora users.

martin, -testing isn't meant for long-term carrying of a package which is not intended to go out as an official update. If this update is not going to go out as-is you should supersede or unpush it, not leave it sitting there :)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #49)
> (In reply to comment #46)
> > I think though I am going to change gnome-shell to use an ELF binary with RPATH
> > set.  But I'm commenting on this bug so other xulrunner consumers know that
> > they probably need to change.
> 
> Please do that change for rawhide. We're going to keep it in testing for F14 so
> it should not affect common Fedora users.

Any upstream changes (I don't think Colin's plan *quite* works, but we can possibly come up with something else) are unlikely to happen until after the holidays, so we urgently need this incompatible xulrunner change reverted in rawhide.

I guess everyone who is using rawhide in pre-alpha should be able to downgrade xulrunner because of the gnome-shell but okay, 
it's building as xulrunner-2.0-0.13b8.fc15

Note, even after the revert, libjgs will still have issues because it wants JS_GetStringBytes which has been killed.  This probably should get its own bug though...

https://bugzilla.mozilla.org/show_bug.cgi?id=607292
https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_GetStringBytes

Thanks for the fix Martin!

(In reply to comment #53)
> Note, even after the revert, libjgs will still have issues because it wants
> JS_GetStringBytes which has been killed.  This probably should get its own bug
> though...
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=607292
> https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_GetStringBytes

gjs-0.7.8 which I rolled yesterday is already fixed for that - haven't had a chance to run it and the dependency g-i package through koji yet.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Just start anjuta
2.
3.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1.Applications
2.Programming
3.Anjunta


Comment
-----
Apllied the following suggestion:

setsebool -P allow_execstack 1 from bug report 662998

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Start Anjuta from Menu.
2. Show a window.
3. Now, crashes.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Just clicked to open
2.
3.


Comment
-----
Installed with yum and clicked to start from GNOME Applications menu

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. I installed Anjuta throu Add/Remove Software (GNOME's PackageKit front-end).
2. I ran the Dev Helper through a link provided in said package manager.
3. I then tried to run Anjuta, and after the splash screen, was informed that it crashed.


Comment
-----
I had Totem open playing a video as well as Firefox.  I didn't do anything else other than the steps above.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Install anjuta
2.Try to launch, no matter how. Both commandline "$ anjuta" and Gnome menu click fails.
3.


Comment
-----
Anjuta was installed by GUI tool with System -> Administration -> Add/Remove software.

# yum list anjuta
Installed Packages
anjuta.i686                                                1:2.31.90.0-1.fc14                                                @fedora

$ anjuta 

** (anjuta:21059): WARNING **: Can't find libsqlite3.so file.

(anjuta:21059): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

(anjuta:21059): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

** (anjuta:21059): WARNING **: Can't find libsqlite3.so file.

(anjuta:21059): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

** (anjuta:21059): WARNING **: Can't find libsqlite3.so file.

(anjuta:21059): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

(anjuta:21059): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

** (anjuta:21059): CRITICAL **: gda_server_provider_supports_feature: assertion `GDA_IS_SERVER_PROVIDER (provider)' failed

** (anjuta:21059): WARNING **: Can't find libsqlite3.so file.

(anjuta:21059): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

(anjuta:21059): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(anjuta:21059): libanjuta-symbol-db-WARNING **: Could not open connection to DB_DIR=/home/vvvf14/.cache/anjuta;DB_NAME=.anjuta_sym_db


libanjuta-symbol-db-ERROR **: Opening global project under /home/vvvf14/.cache/anjuta
aborting...
Aborted (core dumped)
$



It happened the same day also on different hardware (laptop Dell XPS M1530).

(In reply to comment #39)
> I'll check if we can rename the xulrunner sqlite3 library.
(In reply to comment #40)
> Please check xulrunner-1.9.2.13-2.fc14.

# yum install xulrunner-1.9.2.13-2.fc14
[...]
No package xulrunner-1.9.2.13-2.fc14 available.
Error: Nothing to do


(In reply to comment #0)
> Setting LD_LIBRARY_PATH=/usr/lib64 is a workaround for this bug
(In reply to comment #3)
> By setting LD_LIBRARY_PATH, you were just bypassing the linker cache.

Workaround for x86:
# ln -s /usr/lib/libsqlite3.so.0.8.6 /usr/lib/libsqlite3.so
$ LD_LIBRARY_PATH=/usr/lib anjuta

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. start anjuta
2. it seems to be complaining about missing libsqlite3.so
3. it aborts


Comment
-----
seems to be problem in symbols_db_plugin

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
Try to launch Anjuta

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. installed using yum
2. run it by clicking the icon in the "Applications->Programming" menu
3.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. I installed Anjuta and started it.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. installed anjuta from repository
2. started anjuta from menu
3.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. $ sudo yum install anjuta (also pulls in about 10 dependencies)
2. $ anjuta


Comment
-----
This is a completely normal install and the first invocation coredumps.  Suprised.  Reboot the machine and re-invoke from gnome application list, and same coredump occurs in the pthread library.  Machine is an Athlon64 running F14 x64 upgraded in-place from F13.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. upon starting the application
2.
3.

xulrunner-1.9.2.13-3.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/xulrunner-1.9.2.13-3.fc14

Please let me know when I can remove ld.so.conf.d file in rawhide. I'll try to rename xulrunner sqlite library for F14.

Upstream bug - https://bugzilla.mozilla.org/show_bug.cgi?id=513747

xulrunner-1.9.2.13-5.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xulrunner'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xulrunner-1.9.2.13-5.fc14

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. upon startup
2.
3.


Comment
-----
Installed the test xulrunner, same outcome.

Package: anjuta-1:2.31.90.0-1.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Just open the application.
2.
3.

xulrunner-1.9.2.13-5.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

I tried to follow up, reading all comments, but may be missed something.

https://admin.fedoraproject.org/updates/libgda-4.2.2-1.fc14

Any plans about pushing/fixing this ?

@Rakesh: that update didn't solve everyone's issue, you should try the xulrunner update before.

(In reply to comment #77)
> @Rakesh: that update didn't solve everyone's issue, you should try the
> xulrunner update before.

Ok, I will see and report.

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

using the new xulrunner and installing sqlite-devel is sufficient for me. I do not need the libgda and libgda-sqlite updates from testing:

This are the packages I use on 2.6.35.10-74.fc14.x86_64:

anjuta-2.31.90.0-1.fc14
xulrunner-1.9.2.13-5.fc14
sqlite-devel-3.6.23.1-1.fc14
libgda-4.2.0-1.fc14
libgda-sqlite-4.2.0-1.fc14

libgda-4.2.2-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/libgda-4.2.2-2.fc14

i got the uypgrade - problem still happens
i fixed by
 yum install libsqlite3*

it responded
snip
Transaction Test Succeeded
Running Transaction
  Installing     : libsqlite3x-20071018-9.fc14.i686                         1/3 
  Installing     : sqlite-devel-3.6.23.1-1.fc14.i686                        2/3 
  Installing     : libsqlite3x-devel-20071018-9.fc14.i686                   3/3 

Installed:
  libsqlite3x.i686 0:20071018-9.fc14  libsqlite3x-devel.i686 0:20071018-9.fc14 

Dependency Installed:
  sqlite-devel.i686 0:3.6.23.1-1.fc14    

and the problem is fixed

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

Please also push fixed firefox to rawhide. Thanks!

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

libgda-4.2.2-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

doh it still crashed for me on startup.
maybe its my system but i do seem to have that lib update installed already:

anjuta-1:2.32.1.1-1.fc14 (x86_64)
libgda-1:4.2.2-2.fc14 (x86_64)

Created attachment 478162 [details]
crashreport from abrt that sent me to this bug report but looks different

hmm maybe not same bug.

i ended up at this bug because abrt sent me here but it looks like it might be a different one.  

see attached crashreport.

hmm yah it looks more like https://bugzilla.redhat.com/show_bug.cgi?id=670058

duno why abrt dumped me here doh.

@callura: As of commment #82, try

yum install sqlite3*

(In reply to comment #26)
> The fact is that xulrunner ships libsqlite3.so which overrides any other *.so.*
> The solution is as simple as to create a symlink:
> 
> ln -s /usr/lib64/libsqlite3.so.0.8.6 /usr/lib64/libsqlite3.so
> 
> You may prefer to install sqlite-devel (which ships that symlink) to avoid
> conflicts.

Thanks. I can start Anjuta successfully.

loaded devel and it anjuta launches successfully now thanks.

regarding comment#90, thanks sorry i missed comment#82.  my eyes went buggy around comment 60 though i just reskimmed the early comments and see i also missed comment#26 which which i see someone also reposted in comment#91.  apparently all i could see was the libgda comments lol.

thanks again :')

Just as an additional step, in case the xulrunner changes
don't work, I've submitted a patch to libgda to hopefully resolve this
issue from their side of things. This was discussed with Haïkel Guémar way back in comment 18.

patch report :
https://bugzilla.gnome.org/show_bug.cgi?id=642100

To be honest, applying this change is the only thing that I've found
to reliably resolve this issue for me.

Hope this helps

I just installed sqlit3* as rmknox recommend in comment 82. 
The crash stopped.

When installed libsqlite3x as commented in comment 82

anjuta is working fine....

thanks for all information here in bugzilla.
Best Regards.


(In reply to comment #82)
> i got the uypgrade - problem still happens
> i fixed by
>  yum install libsqlite3*
> 
> it responded
> snip
> Transaction Test Succeeded
> Running Transaction
>   Installing     : libsqlite3x-20071018-9.fc14.i686                         1/3 
>   Installing     : sqlite-devel-3.6.23.1-1.fc14.i686                        2/3 
>   Installing     : libsqlite3x-devel-20071018-9.fc14.i686                   3/3 
> 
> Installed:
>   libsqlite3x.i686 0:20071018-9.fc14  libsqlite3x-devel.i686 0:20071018-9.fc14 
> 
> Dependency Installed:
>   sqlite-devel.i686 0:3.6.23.1-1.fc14    
> 
> and the problem is fixed

I just encountered this issue installing Fedora 14 on x86_64.  The solution in https://bugzilla.redhat.com/show_bug.cgi?id=658471#c26 worked for me.