> > On 02/20/14 20:11, Brad Smith wrote: > > > On 31/01/14 9:10 PM, Philip Guenther wrote: > > >> On Wed, 29 Jan 2014, Sviatoslav Chagaev wrote: > > >>> When unloading, ld.so removes elements from grpref list too soon, not > > >>> allowing code which runs later to destroy objects in the list. Next time > > >>> we dlopen, there are undead objects with e.g. freed elements in child > > >>> list. Sooner or later something bad happens, in my case div by zero. > > >>> > > >>> Patch: > > >> > > >> Your patch reverts this commit: > > >> > > >> ---------------------------- > > >> revision 1.34 > > >> date: 2011/07/13 20:49:44; author: drahn; state: Exp; lines: +4 -2; > > >> Delete items on grpreflist when walking them to decrement the count, > > >> otherwise double decrement can occur. ok kurt@ timeout on other > > >> reviewers. > > >> ============================================================================= > > >> > > >> > > >> I'm not sure if there's a regress for the issue Dale was fixing, but > > >> simply reverting his fix and reintroducing the original problem isn't > > >> much > > >> better than where we are now. > > >> > > >> I'll stare at this some and see if I can see how to avoid leaving group > > >> leaders on the global list... > > > > > > Any update on this? > > > > Any chance this issue could be looked into? As more projects are adding > > support for or switching to SDL2 there has been more interest from > > porters to use SDL2 but it is marked broken due to this issue. > > > > Hi, > > I propose to remove grpref_list altogether because it doesn't seem to > have any real purpose. > > It's used in two places in code: for debug output (dlfcn.c:227) and > when unloading objects to seemingly prevent unloading an object which > is in use. The information it outputs can already be inferred from the > rest of output and we already have opencount and refcount reference > counters which will prevent unload of a used object. > > Tested on amd64 current, running Firefox, GIMP, Sylpheed, mplayer; > the synthetic test doesn't crash anymore and I also built SDL2 from > ports and ran a few simple programs which use it > (https://github.com/S010/test/tree/master/sdl2), seems to work fine. > >
I can confirm that this fixes sdl2 for me on amd64 on -current, Alf