> > 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
