This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 658471 - Removal of xulrunner ld.so.conf.d file
Removal of xulrunner ld.so.conf.d file
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xulrunner (Show other bugs)
14
x86_64 Linux
high Severity high
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
: Triaged
: 651859 654399 657368 667828 669640 670138 (view as bug list)
Depends On:
Blocks: 657560
  Show dependency treegraph
 
Reported: 2010-11-30 08:41 EST by ardee
Modified: 2011-03-14 17:55 EDT (History)
51 users (show)

See Also:
Fixed In Version: libgda-4.2.2-2.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-04 15:58:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
crappy looking patch fixing sqlite3 loading (1.16 KB, patch)
2010-11-30 12:38 EST, Haïkel Guémar
no flags Details | Diff
crashreport from abrt that sent me to this bug report but looks different (17.14 KB, text/plain)
2011-02-10 19:54 EST, collura
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 513747 None None None Never

  None (edit)
Description ardee 2010-11-30 08:41:24 EST
Description of problem: 
When using an application that depends on libgda - sqlite3 provider, startup fails with the following :-

WARNING **: Can't find libsqlite3.so file
(gda-sql-4.0:2012): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

The application then (usually) aborts.

In my case this is causing Anjuta to fail to launch as it depends on this component.

However, running the following command:
   #LD_LIBRARY_PATH=/usr/lib64 gda-sql-4.0 -L

succeeds without error.
After looking at the source for lbgda, the function:
    find_sqlite_library (const gchar *name_part)

Checks for the libsqlite3.so shared object and is failing. It tries PATH, then LD_LIBRARY_PATH and lastly ..." then use the compile time SEARCH_LIB_PATH "

This is on X86_64 - perhaps the package needs rebuilt with /usr/lib64 as its SEARCH_LIB_PATH ?

Version-Release number of selected component (if applicable):
uname -r
  2.6.35.6-48.fc14.x86_64

yum info libgda-sqlite
  Version     : 4.2.0
  Release     : 1.fc14

How reproducible:
every time

Steps to Reproduce:
1. Run command:  gda-sql-4.0 -L
2. Observe messages on screen
3. Run Anjuta, application fails to start (abort) after displaying
same messages.


Additional info:
Setting LD_LIBRARY_PATH=/usr/lib64 is a workaround for this bug
Comment 1 Haïkel Guémar 2010-11-30 12:38:48 EST
Created attachment 463787 [details]
crappy looking patch fixing sqlite3 loading
Comment 2 ardee 2010-11-30 13:11:11 EST
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,
Comment 3 Haïkel Guémar 2010-11-30 15:24:36 EST
> 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.
Comment 4 Haïkel Guémar 2010-11-30 17:29:30 EST
For testing purpose:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2635940
Comment 5 Juan Francisco Cantero Hurtado 2010-12-04 22:31:01 EST
I have the same problem with anjuta in x86. With the new rpm of libgda and libgda-sqlite all works OK. Thanks :)
Comment 6 Fedora Update System 2010-12-06 08:38:54 EST
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
Comment 7 Fedora Update System 2010-12-06 15:04:02 EST
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
Comment 8 Rakesh Pandit 2010-12-07 02:36:18 EST
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.
Comment 9 nathanielnicandro 2010-12-12 16:15:29 EST
I used the update to libgda and reinstalled anjuta and I still get the same error that everyone else is getting.
Comment 10 Johannes Schmid 2010-12-13 11:18:48 EST
*** Bug 651859 has been marked as a duplicate of this bug. ***
Comment 11 Johannes Schmid 2010-12-13 11:21:15 EST
*** Bug 654399 has been marked as a duplicate of this bug. ***
Comment 12 Johannes Schmid 2010-12-13 11:30:59 EST
*** Bug 657368 has been marked as a duplicate of this bug. ***
Comment 13 Johannes Schmid 2010-12-13 11:35:31 EST
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
Comment 14 Dawid Zamirski 2010-12-13 23:55:35 EST
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)
Comment 15 Sergey Sedov 2010-12-14 04:37:48 EST
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...
Comment 16 Johannes Schmid 2010-12-14 05:00:28 EST

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Johannes Schmid 2010-12-14 05:07:29 EST
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
Comment 18 ardee 2010-12-14 06:07:19 EST
(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
Comment 19 Johannes Schmid 2010-12-14 06:36:03 EST
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
Comment 20 Haïkel Guémar 2010-12-14 15:25:38 EST
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.
Comment 21 mirek 2010-12-16 15:07:33 EST
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
Comment 22 schuster.bernhard 2010-12-17 11:38:47 EST
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
Comment 23 Tuomas Ritola 2010-12-17 11:59:51 EST
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).
Comment 24 schuster.bernhard 2010-12-17 12:09:30 EST
The package from update testing does NOT fix the issue
Comment 25 Haïkel Guémar 2010-12-17 12:43:26 EST
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
Comment 26 Frank 2010-12-18 07:56:50 EST
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.
Comment 27 schuster.bernhard 2010-12-18 08:08:03 EST
I can confirm that the solution installing sqlite-devel from coment 26 works perfectly
Comment 28 Tuomas Ritola 2010-12-18 09:06:47 EST
Installing sqlite-devel did not fix it for me.
Comment 29 schuster.bernhard 2010-12-18 10:39:14 EST
I can confirm that the solution installing sqlite-devel from coment 26 works perfectly
Comment 30 arnost.zlicin 2010-12-18 11:38:43 EST
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.
Comment 31 enzo 2010-12-18 17:20:49 EST
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
Comment 32 Philip Chimento 2010-12-18 20:42:31 EST
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.
Comment 33 Jediah Logiodice 2010-12-18 21:48:49 EST
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
Comment 34 Gregor Hlawacek 2010-12-19 08:06:07 EST
I confirm that updating libgda from updates-testing and installing sqlite-devel solves the issue.
Comment 35 Wil 2010-12-19 10:10:31 EST
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
Comment 36 Majdak Aleksandar 2010-12-19 11:54:04 EST
Updating libgda from testing and installing sqlite-devel solves this issue.
Comment 37 Christian A. Reiter 2010-12-19 15:50:54 EST
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
Comment 38 Christian A. Reiter 2010-12-19 16:02:07 EST
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!
Comment 39 Martin Stransky 2010-12-20 02:37:23 EST
I'll check if we can rename the xulrunner sqlite3 library.
Comment 40 Martin Stransky 2010-12-20 07:06:37 EST
Please check xulrunner-1.9.2.13-2.fc14.
Comment 41 Fedora Update System 2010-12-20 07:08:14 EST
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
Comment 42 Haïkel Guémar 2010-12-20 13:30:23 EST
@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.
Comment 43 Illya 2010-12-20 13:54:21 EST
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.
Comment 44 Keith Mc Dowell 2010-12-21 01:57:07 EST
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..
Comment 45 Saggi Mizrahi 2010-12-21 09:27:38 EST
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
Comment 46 Colin Walters 2010-12-21 15:15:25 EST
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.
Comment 47 Adam Williamson 2010-12-21 19:05:40 EST
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
Comment 48 Johannes Schmid 2010-12-21 21:18:44 EST
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.
Comment 49 Martin Stransky 2010-12-22 03:07:51 EST
(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.
Comment 50 Adam Williamson 2010-12-22 05:24:22 EST
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
Comment 51 Owen Taylor 2010-12-22 11:39:59 EST
(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.
Comment 52 Martin Stransky 2010-12-23 03:04:21 EST
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
Comment 53 Christopher Aillon 2010-12-23 15:21:30 EST
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
Comment 54 Owen Taylor 2010-12-23 17:29:46 EST
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.
Comment 55 Paolo Niccolò Giubelli 2010-12-24 10:35:30 EST
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.
Comment 56 Keith Mc Dowell 2010-12-24 22:25:44 EST
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
Comment 57 Mike Ma 2010-12-25 03:19:14 EST
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.
Comment 58 Umit Bozkir 2010-12-27 07:06:30 EST
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
Comment 59 Thomas Holbrook II 2010-12-27 09:22:18 EST
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.
Comment 60 Vladimir Vinogradov 2010-12-28 12:06:07 EST
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).
Comment 61 Vladimir Vinogradov 2010-12-28 13:43:55 EST
(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
Comment 62 Lukas Bezdicka 2010-12-28 18:02:24 EST
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
Comment 63 Gendre Sébastien 2010-12-29 17:28:17 EST
Package: anjuta-1:2.31.90.0-1.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
Try to launch Anjuta
Comment 64 Xi Yang 2010-12-29 20:32:36 EST
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.
Comment 65 Hadrien Grasland 2010-12-30 09:33:20 EST
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.
Comment 66 Corinna Blau 2011-01-01 06:48:51 EST
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.
Comment 67 John Mellor 2011-01-01 13:16:00 EST
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.
Comment 68 placitum 2011-01-01 19:15:08 EST
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.
Comment 69 Fedora Update System 2011-01-03 06:29:35 EST
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
Comment 70 Martin Stransky 2011-01-03 06:55:08 EST
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.
Comment 71 Martin Stransky 2011-01-03 07:15:03 EST
Upstream bug - https://bugzilla.mozilla.org/show_bug.cgi?id=513747
Comment 72 Fedora Update System 2011-01-03 15:00:57 EST
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
Comment 73 placitum 2011-01-03 21:26:54 EST
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.
Comment 74 seby 2011-01-04 10:11:54 EST
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.
Comment 75 Fedora Update System 2011-01-04 15:58:12 EST
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.
Comment 76 Rakesh Pandit 2011-01-05 00:55:30 EST
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 ?
Comment 77 Haïkel Guémar 2011-01-05 01:40:44 EST
@Rakesh: that update didn't solve everyone's issue, you should try the xulrunner update before.
Comment 78 Rakesh Pandit 2011-01-05 02:49:34 EST
(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.
Comment 79 Johannes Schmid 2011-01-06 18:30:33 EST
*** Bug 667828 has been marked as a duplicate of this bug. ***
Comment 80 Gregor Hlawacek 2011-01-07 02:47:36 EST
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
Comment 81 Fedora Update System 2011-01-08 11:23:15 EST
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
Comment 82 rmknox 2011-01-09 12:58:49 EST
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
Comment 83 Johannes Schmid 2011-01-14 04:21:42 EST
*** Bug 669640 has been marked as a duplicate of this bug. ***
Comment 84 Johannes Schmid 2011-01-14 04:23:33 EST
Please also push fixed firefox to rawhide. Thanks!
Comment 85 Johannes Schmid 2011-01-17 05:57:59 EST
*** Bug 670138 has been marked as a duplicate of this bug. ***
Comment 86 Fedora Update System 2011-02-07 14:51:27 EST
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.
Comment 87 collura 2011-02-10 19:45:13 EST
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)
Comment 88 collura 2011-02-10 19:54:19 EST
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.
Comment 89 collura 2011-02-10 19:59:25 EST
hmm yah it looks more like https://bugzilla.redhat.com/show_bug.cgi?id=670058

duno why abrt dumped me here doh.
Comment 90 Johannes Schmid 2011-02-11 03:36:18 EST
@callura: As of commment #82, try

yum install sqlite3*
Comment 91 Mike Ma 2011-02-11 04:19:37 EST
(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.
Comment 92 collura 2011-02-11 13:56:01 EST
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 :')
Comment 93 ardee 2011-02-12 06:08:54 EST
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
Comment 94 llzzccc 2011-02-27 20:07:17 EST
I just installed sqlit3* as rmknox recommend in comment 82. 
The crash stopped.
Comment 95 Pedro Jorge Viana 2011-03-05 12:34:56 EST
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
Comment 96 Guy Rouillier 2011-03-14 17:09:10 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.