On 3/22/06, Steve Langasek <[EMAIL PROTECTED]> 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. Cheers, -- stratus