Subject: Re: fribidi problem
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Sun Nov 25 2001 - 08:29:17 CST
> > Strictly speaking, this is not a fribidi problem, it just uses glib, and
> > if we did use glib for our memory management it probably would
> > not happen. Though, I am puzzled why this should be happening at
> > all.
>
> Doesn't make sense to me either, unless memory is being freed somewhere
> but then used afterwards anyway (by which time it has been reallocated
> elsewhere...)
>
They use g_mem_chunk_new to allocate an area of memory, and
then they use g_chunk_new to allocate varibles withing this chunk.
The problem seems to be that the chunk is not locked or
something and so new allocates over a portion of it. I have just
been looking at glib source code and it from what I saw it is
possible that glib uses a different allocator from malloc; I do not
know whether this is the case here (although it would explain the
problem), but the very fact it could be, makes me think that we
need to get rid of the g_malloc calls in the fribidi library, and
perhaps elsewhere.
To answer Andrew's question, there is a way to compile fribidi
without glib, it comes with its mini-glib, and I will see if using it
makes any difference; on win32 we simply used the mini-glib that
is included with wv. The fribidi mini-glib contains only couple of
macros, among others redefining g_malloc to malloc, and a single
function to do with glists. I am going to test whether using this will
resolve the problem, and if it does, this would be a painless
solution which would not require forking.
Tomas
This archive was generated by hypermail 2b25 : Sun Nov 25 2001 - 08:30:17 CST