Re: for those who care about GNOME^w glib applications.
On 3/22/06, Steve Langasek <email@example.com> wrote:
> On Wed, Mar 22, 2006 at 11:29:01AM -0300, Gustavo Franco wrote:
> > > > 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?
> > Yes, the new GSlice allocator is triggering those bugs. It happens due to
> > different (but similar) reasons, e.g: In nettool and galculator 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.
> Right, I saw the patch posted to the evolution bug, which made perfect sense
> -- objects are being allocated via one API and then being freed by another,
> unrelated API that happened to work before because they were both
> implemented on top of malloc()/free().
Yes, evo was NMUed.
> So, unquestionably an application bug.
> > 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.
> It works because g_free() is a wrapper around free(), so if the address
> passed to g_free() doesn't point to memory allocated using malloc(), glibc
> will abort as shown. Making sure everything is allocated with malloc()
> works around this.
Oh, i see. Thanks!
> > 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 based on
> > the bugs already
> > opened. Hopefully it's less grave than you think.
> Ok, seems like you have this under control then. :)
Yes, just a few bugs reported and probably two without a patch
(classpath and gnome-games) atm. The others were patched through the
BTS, NMUed or Ubuntu has a fix. I'll take a look into the classpath,
but the bug was already forwarded to the upstream, so there's a
possibility that they've a patch.