2.4.6 gconfd-2 repeated crashes OS X

John Ralls jralls at ceridwen.us
Thu Jun 2 18:11:40 EDT 2011


On Jun 1, 2011, at 11:39 PM, Mike Alexander wrote:

> --On June 1, 2011 9:54:00 PM -0700 John Ralls <jralls at ceridwen.us> wrote:
> 
>> 
>> On Jun 1, 2011, at 9:26 PM, Richard Nelson wrote:
>> 
>>> John,
>>> 
>>> Thanks for the help in rolling back to 2.4.5; it worked perfectly
>>> and I'm a happy camper now. I'm also a total noob and want to make
>>> sure that this is what you want before I try filing a bug report.
>>> Thanks again for your help.
>>> 
>>> Richard
>>> 
>>> Process:         gconfd-2 [1161]
>>> Path:
>>> /Applications/Gnucash.app/Contents/Resources/libexec/gconfd-2
>>> Identifier:      gconfd-2
>>> Version:         ??? (???)
>>> Code Type:       X86 (Native)
>>> Parent Process:  dbus-daemon [1160]
>>> 
>>> Date/Time:       2011-06-01 08:55:37.993 -0700
>>> OS Version:      Mac OS X 10.6.7 (10J869)
>>> Report Version:  6
>>> 
>>> Interval Since Last Report:          214 sec
>>> Crashes Since Last Report:           4
>>> Per-App Crashes Since Last Report:   8
>>> Anonymous UUID:
>>> 59691E50-67C6-4B32-AFD4-9FB8BD377647
>>> 
>>> Exception Type:  EXC_BREAKPOINT (SIGTRAP)
>>> Exception Codes: 0x0000000000000002, 0x0000000000000000
>>> Crashed Thread:  0
>>> 
>>> Dyld Error Message:
>>> Library not loaded:
>>> @executable_path/../Resources/lib/libgconf-2.4.dylib Referenced
>>> from: /Library/Gnucash-2.4/libexec/gconfd-2
>>> Reason: image not found
>>> 
> 
> Your build of gconfd can't use @executable_path to find its libraries since gconfd is being loaded by the dbus process started by launchd and @executable_path won't be what you want, if it's anything at all.  I would suggest that you build everything with their dynamic libraries at /Library/Gnucash-2.4/lib (which is the same as @executable_path/../Resources/lib because of your symlink), then the symlink will find the libraries.  This isn't necessary for libraries loaded by GnuCash itself, but it won't hurt and it simplifies things if all libraries are built the same way.
> 
> I don't know why this worked when you tested it.  You must have had some version of the relevant libraries in your search path.  It didn't work for me when I tried it on a plain vanilla test ID I keep around for this purpose.
> 
> While testing this using a different userid, not the one that installed GnuCash, I discovered another problem.  Launchctl refuses to load ~/Library/LaunchAgents/org.freedesktop.dbus-session.plist because the plist file (the target of the symlink) belongs to the wrong user when gnucash is run from a user other than the one that installed it. Changing the owner of Gnucash.app/Contents/Resources/etc/dbus-1/org.freedesktop.dbus-session.plist to root:wheel fixes this problem.  I don't know if changing this in the bundle on the install disk is enough to fix this or if it will get reset when the bundle is copied to the Applications directory.  At any rate this is a secondary error since it only affects machines where more than one user runs GnuCash.

I'm pretty sure that I got it to run on a machine other than the build machine, but now I can't... and I never was able to on the PPC machine.

The rpath is changed during bundle creation. Everything is built with a prefix of /Library/Gnucash-2.4; that's why the symlink works. (It's necessary because dbus has hardcoded paths in it, apparently because Havoc thinks that makes it more secure. Ideally there would be no need for the symlink and the kludgy shell script to set it up.) The rpath is just as invalid when dbus-daemon is started from the shell script. What's different, I think, is in that case the environment, including DYLD_LIBRARY_PATH, gets passed to gconfd and it can find its dependencies. It appears that when launchd handles launching dbus-daemon that the environment is not passed to gconfd, so it can't.

No matter, it's easy enough to go back to the shell script until I have time to get rid of dbus and gconf altogether.

Regards,
John Ralls





More information about the gnucash-user mailing list