On Wednesday 24 July 2002 22:21, Jon Keating wrote: > On Wednesday 24 July 2002 12:30 pm, Lubos Lunak wrote: > > On Tuesday 23 July 2002 03:07, Jon Keating wrote: > > > On Sunday 21 July 2002 02:04 pm, Lubos Lunak wrote: > > > > I think I understand what the problem is. Maybe a bit tough to solve > > > > though. The reason for the crash is quite simple. LICQ binary has its > > > > own malloc(), coming from libc, and kdelibs have their own > > > > (different) malloc(). After dlopening the KDE GUI module, functions > > > > in the module use different malloc() than those in the main binary, > > > > and this leads to crash (I think it should only crash if the module > > > > tries to free something allocated by the binary or vice versa, but > > > > apparently it happens). > > > > > > Ahh, that makes sense. > > > > [snip] > > > > > So obviously, that is not correct. Anymore ideas? > > > > Hmm, yes, -Wl,--export-dynamic wasn't a correct solution, I forgot that > > malloc() is in libc and not in the binary. But I think I have the right > > solution now. There are actually more ways to solve the problem. > > > > When the dynamic loader resolves symbols, it searches all the libraries > > in the link order, until it finds the symbol. For licq with KDE plugin, > > the libraries are like this: > > > > licq binary | kde-licq plugin | kdelibs | qt | ... | libc > > > > There are two malloc() implementation, one in libc, the other in > > kdelibs. When the plugin is not yet loaded, items 2-4 are not there yet, > > so when searching from left to right, malloc() is found only in libc. > > When the plugin is dlopened, the search goes again from left to right, > > but this time malloc() is found already in kdelibs ... => trouble. > > > > There are three solutions how to make the plugin use the same malloc() > > as the binary : > > - remove malloc() from kdelibs - I don't think there are enough reasons > > to make me do this > > - add malloc() to the binary - both the binary and the plugin will use > > this malloc() (don't forget -Wl,--export-dynamic in this case). You can > > just take kdelibs/kdecore/malloc and use it, if you want. > > - add another malloc() to the plugin, that will skip the faster malloc() > > in kdelibs and use the libc one - see the attached patch and source, they > > belong to licq/plugins/qt-gui/src. Probably the easiest solution. > > I'm using the 3rd option since I did not want to put KDE's malloc() into > the licq binary. The latest CVS has your patch for the code. The only > concern I have is on systems that don't have libc.so or libc.so.6. Is this > anything to be concerned about? > > Thanks! > > Jon > > ______________________________________________________________ > Jon Keating ICQ #16325723 > [EMAIL PROTECTED] GPG ID: 0x2290A71F > emostar on irc.openprojects.net > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Licq-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/licq-devel
it solved all the bugs i was experiencing, thanks for the patch jon, licq works flawlessly now:))) best regards... -- Paulo Dias [EMAIL PROTECTED] [EMAIL PROTECTED] icq: 15544538 WebProgrammer/WebDesigner ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim _______________________________________________ Licq-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/licq-devel
