|
From: Christian P. <tr...@ge...> - 2005-08-12 07:22:35
|
> Unfortunately, this "Invalid read" doesn't help me, especially, when only=
a
> stupid dlclose() being commented out can fix this;
>
> maybe the daemon is still accessing memory that *was* part of the
> dlopen()ed module - can that be true?
When running VG with -v I _believe_ I got the prove;
[...]
Unloading module character
=2D-20983-- discard syms at 0x1593D5000-0x1595A0000=20
in /opt/sandbox/swl/0.4/lib/yacs/mod_character.so due to munmap()
[...]
Unloading module chat
=3D=3D20983=3D=3D Invalid read of size 8
[...]
=3D=3D20983=3D=3D Address 0x15959CE90 is not stack'd, malloc'd or (recentl=
y) free'd
[...]
Well then, neither the backtrace nor the "Invalid read" told me exactly at=
=20
what location (memory address) this read error occured, however in the end,=
I=20
get the message above ("0x15959CE90 is not stack'd, malloc'd or free'd")
Looking at the area mmap'd via dlopen() I see that this address is within t=
he=20
range (however it came to that result), so, finally, maybe VG should rememb=
er=20
those mmap's for afterlife reads/writes within such ranges (to be reported=
=20
more clearly);
So, if I'm really right here, is there a way to get such a observation feat=
ure=20
into VG for 3.1?
Best regards,
Christian Parpart.
=2D-=20
09:14:02 up 141 days, 22:21, 0 users, load average: 1.02, 1.16, 1.14
|