Just to summarize / save anyone else from digging through all those links, it seems the issue is that objects allocated with one API were being freed by another (I didn't see what the allocation API was, but the "free"s in question were g_free (incorrect) and g_object_unref (correct). g_free() is a wrapper around free() which means that it happens to work if the allocation API ends up being a wrapper around malloc() (which is why always-malloc works around the problem). When the new, more efficient allocator is used instead (which AIUI grabs some large chunks of memory and manages them itself so there are lots of objects per single malloc()ed chunk), free() fails, and so g_free() does too. If classpath is hitting this in the same way everyone else is, it's not a glib bug, it's definitely a Classpath bug. Stuart. On 4/2/06, Wolfgang Baer <WBaer@xxxxxx> wrote: > Roman Kennke wrote: > > Hi Mark, > > > >> Since there was so much talk again about our GdkGraphics2D > >> implementation I tried playing again with it some more. And I noticed it > >> is stabler when running it with: > >> export G_SLICE=always-malloc > >> Otherwise I often would get a > >> *** glibc detected *** free(): invalid pointer: 0x086cdb18 *** > >> This is probably some bug in our code that needs a specific glib > >> allocation strategy to work. But I haven't been able to find any details > >> yet. > > > > According to Dalibor this is probably even a bug in glib. > > This is filed as bug 26803 [0] already. Maybe the debian thread there > might help to find the problem. > > Wolfgang > > [0] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26803 > > > -- http://sab39.dev.netreach.com/
