|
From: Joshua V. <jlv...@gm...> - 2005-08-12 12:36:26
|
On 8/12/05, Christian Parpart <tr...@ge...> wrote: > On Friday 12 August 2005 12:14, Tom Hughes wrote: > > In message <200...@ge...> > > > > Christian Parpart <tr...@ge...> wrote: > > > On Friday 12 August 2005 09:51, Tom Hughes wrote: > > >> In message <200...@ge...> > > > > > > [...] > > > > > >> You've cleverly cut out all the useful/interesting information from > > >> that output... > > > > > > Why I (repeatily) did so, is, because it's a rather bigbig backtrace = and > > > I didn't wanna flood you with maybe not that interesting data as you > > > might got shocked of the bloated backtrace or so; > > > > > > I attached the complete output (95% of them are VG so no flood et al = I > > > hope) > > > > Well that trace looks fairly straightforward to me - there is some > > code in that release method that is accessing memory that was part > > of the plugin and has been released. Presumably a global object given > > that the memory being referenced is part of the .so rather than being > > on the stack or the heap. >=20 > That might be a hint there; thanks; >=20 > is it also possible, that this ill address is once been valid and created= by > the plugin and that their new/malloc method did return an address within = its > own mmap space? >=20 > If that's so, than it's a leak I didn't close and that's why I still have= that > old (orphaned) pointer around in this list; >=20 We've had problems in our code base where SmartPtr's have been trying double delete when linking dynamically. It seems to be some thing related to a global symbol in the library that some how appears in the executable, so that when the library is unloaded the memory is cleared, then when the exectuable is unloaded it tries to clear the memory again. This was fixed by having the SmartPtr zero out it's pointer immediately following the deletion, so that there is nothing to try to delete the second time. If this change fixes it, you may have hit the same kind of weird compiler case that we did. It looks like there are multiple SharedPtr destructors in your call stack, so that could, also, confuse the issue. You could try accessing the raw pointer prior to deleting it to see if it has already been deleted, and by whom. Josh P.S. Is there possibly an inter-plugin dependency? |