[EMAIL PROTECTED] wrote:
>
> Quoting Stefan Seefeld <[EMAIL PROTECTED]>:
>
> > [EMAIL PROTECTED] wrote:
> >
> > Could you be a bit more clear ? There is absolutely nothing wrong with
> > having an application that is linked to libggi, which uses dlopen to
> > plugin modules. I do that every day with the berlin system.
>
> > I don't program in C very often, so I'm not the best person to answer
> > your question. There could be issues about global data initialization, but
> > how exactly that is dealt with I don't know. I usually work in C++, which
> > differs quite a bit, especially with respect to initialization.
>
> That's not the first time I come across this kind of weird problems, and
> I never declare any global variable in my programs. So I really wonder...
> I put a short sample code at:
> http://www.zimzum.info.unicaen.fr/ggi/libgfl-test.tgz
>
> I also have another example of code crashing unexpectedly (with the x-target)
> if I call ggiOpen after a piece of code which has absolutely _nothing_ to do
> with ggi (xml processing), but working ok if I call ggiOpen _before_ processing
> the file. There again, no global state variable involved throughout my code!
>
> It really makes me feel stupid...
> If someone could enlighten me I'll appreciate it very much.
Hi,
Your bug is not related to GGI.
In gfl.c, your calls to calloc are wrong.
r=calloc(sizeof(*r),0);
should be
r=calloc(1, sizeof(*r));
It's really strange that a call to calloc with a 0 argument returns a
valid value (i.e. not NULL)... This call corrupts your heap and it makes
[cm]alloc segfault some time later during ggiOpen. libc bug ?
Xavier
