Date: 29 Jan 2002 00:39:05 -0500 From: Joe Clarke <marcus@marcuscom.com> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Anders Andersson <anders@hack.org>, gnome@FreeBSD.org Subject: Re: deskutils/mrproject Message-ID: <1012282745.93813.64.camel@shumai.marcuscom.com> In-Reply-To: <1012276850.45588.30.camel@notebook> References: <1012183959.78541.11.camel@shumai.marcuscom.com> <20020128143829.T78981-101000@shumai.marcuscom.com> <20020128222637.GB297@sushi.sanyusan.se> <1012263062.93813.4.camel@shumai.marcuscom.com> <1012276850.45588.30.camel@notebook>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2002-01-28 at 23:00, Maxim Sobolev wrote: > Just FYI. I did some digging to identify the real source of the problem > with shared modules. It seems that some fundamental assumptions are > broken. Particularly the software assumes that all shared modules when > loaded share the same namespace, while in fact it isn't always true. For > example, all shared objects share gtk+ namespace, because they are all > linked with it dynamically, but they don't share namespace of > mrproject's utility libraries linked statically. This leads to various > crash patterns, some of them I have fixed, but gave up because there are > many more. > > The typical crash scenario looks like the following: > > 1. The application loads foo.so shared module. The module registers its > custom types with the gtk+ using some utility function linked statically > into each module. This function keeps a state to prevent registering the > same type twice, which is prohibited by gtk+. > > 2. The application loads bar.so shared module. It also tries to register > itself with gtk+ using its own copies of those utility functions. > However, since bar's copy of utility functions aren't shared, bar.so > knows nothing about the fact that some of its types already registered > with gtk+ (gtk+ is shared between foo.so and bar.so), thus leading to a > crash. > > This is one of the most obvious problems. Perhaps there are some more > subtle ones, because even after fixing those ones the software is still > non-functional. > > I think that the problem should be reported to developers, because it > isn't trivial to fix properly. Attached please find some patches to fix > some early startup crashes described above - they should give idea what > I'm talking about. This has been "reported" to the Mr.Project people inasmuch as someone with FreeBSD 4.3 reported the application wouldn't run. the authors decreed it was a FreeBSD issue, and someone from our camp would need to solve it. I spent a lot of time last night looking through Makefiles and source, and concluded it had to be a dynloader issue since libgantt was able to initialize the IdMap object, but once the libnetwork namespace popped up, it failed. The quickest solution I found was to statically link them all into mrproject. This didn't seem too bad since it wasn't nearly as big as say, Evolution. I'd like to take this up with Mr.Project if no one minds. It would be nice to clear this issue up for future releases. Thanks for the patches, Maxim. Joe > > -Maxim > ---- > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-gnome" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1012282745.93813.64.camel>