|
From: Tom H. <to...@co...> - 2005-08-12 10:14:40
|
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.
>> > Well then, neither the backtrace nor the "Invalid read" told me
>> > exactly at what location (memory address) this read error occured,
>> > however in the end, I get the message above ("0x15959CE90 is not
>> > stack'd, malloc'd or free'd")
>>
>> The invalid read should most certainly have told you where the read
>> was occurring. In what way was it not clear.
>
> Yeah, and - in my eyes - it makes no sense to SEGV there; welll, of course
> anywhere in there is a bug, and I start think of having a problem in shared
> pointers (template<class T> TSharedPtr) and traces / symbolnames often become
> unreadable as the demangling algorithm doesn't demangle into the source-level
> used typedef's - of course, I know why it can't - but anyways, it makes it
> harder to read;
I'm not sure what else you expect valgrind to tell you - even if the
plugin was still mapped I don't think it would have been able to tell
you anything more about the bad access in this case.
>> > So, if I'm really right here, is there a way to get such a
>> > observation feature into VG for 3.1?
>>
>> What exactly is it you want 'observed' exactly?
>
> a message like "The memory accessed is within a dlopen()ed region already
> released (dlclose()d)" right below the "invalid read" or alike;
We don't actually know it was dlopened/closed as such - all we know is
that some memory was mapped and then unmapped again.
I guess we could remember that history for a while like we do with
free blocks but it seems like it would have very marginal benefit.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|