[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: for those who care about GNOME^w glib applications.

On 3/22/06, Steve Langasek <vorlon@debian.org> 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[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.
> 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[3] 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.

-- stratus

Reply to: