Tomas Frydrych wrote: >>>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.
Pointing out the obvious... we already use another library that does plenty of g_malloc's... gtk+ (or am I missing something?). Tomas, all you 100% confident that g_malloc is the real problem? Please, can you explain what's giving you the feeling that g_malloc &/| g_mem_chuck_new are the real problem? Cheers, -- Joaquin Cuenca Abela [EMAIL PROTECTED]
