Re: for those who care about GNOME^w glib applications.
On 3/22/06, Steve Langasek <vorlon@debian.org> 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/pkgreport.cgi?users=stratus@debian.org;tag=gslice
Cheers,
-- stratus
Reply to: