On 3/22/06, Steve Langasek <[EMAIL PROTECTED]> wrote: > Hi Gustavo, > > On Tue, Mar 21, 2006 at 11:42:49AM -0300, Gustavo Franco wrote: > > Well, if you're running your favourite glib application and it seems > > to be broken with the output like: > > (...) > > *** glibc detected *** free(): invalid pointer: 0x08ced388 *** > > > It's probably due to the new glib (GSlice) memory allocator[0], but > > it's an application bug. Please first check if it's really glib > > related[1]. > > > There's a workaround that is run the application as follows: > > $ G_SLICE=always-malloc application > > Thanks for the information. Can you explain (or provide a pointer to) why > these bugs are application bugs rather than bugs in glib, and does glib need > to be adding << conflicts with those applications in order to avoid broken > partial upgrades? >
Hi Steve, Yes, the new GSlice allocator is triggering those[0] bugs[1]. It happens due to different (but similar) reasons, e.g: In nettool and galculator[2] the code should call g_object_unref() - that decrease the ref count and frees the memory when the ref count is zero, instead call g_free() directly. FYI, GMemChunk (old and deprecated by the upstream) was reimplemented to use GSlice, so no need to change or rebuild code to be affected due to buggy code. I don't know exactly why asking GSlice to force allocate and free memory through "standard malloc" solves the problem, maybe someone else can clarify this point. Talking about the << conflicts thing. The fact that we don't have a list of affected applications yet, i'm working on a partial list[3] based on the bugs already opened. Hopefully it's less grave than you think. [0] = http://bugzilla.gnome.org/show_bug.cgi?id=329344 [1] = http://bugzilla.gnome.org/show_bug.cgi?id=163639 [2] = http://bugs.debian.org/358064 [3] = http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];tag=gslice Cheers, -- stratus