|
From: tom f. <tf...@al...> - 2009-08-11 17:03:58
|
Jonathon <the...@gm...> writes: > Thanks Tom for the help. The --db-attach command is very cool :) np. > So with the invalid read, it is trying to read an address that is not > valid. Would you happen to know what the line "16 bytes inside a > block 24 free'd" means? I think it's telling you where the chunk of memory became invalid. I'd have to check the docs for the 16 and 24, but maybe the allocator gave a 24-byte block and the pointer that is invalid points to 16 of them. > I am using an std::list. Is it possible the problem is in the list? > and not my actual code? Possible? Technically, yes. Exceedingly unlikely. I (highly) recommend -D_GLIBCXX_DEBUG -D_GLIBCXX_CONCEPT_CHECKS when using the STL w/ libstdc++. -tom > On Tue, Aug 11, 2009 at 9:13 AM, tom fogal<tf...@al...> wrote: > > Jonathon <the...@gm...> writes: > >> I was wondering if it is possible to get valgrind to make an "assert" > >> so my debugger can catch it when a memory error occurs? I would like > >> to determine what is causing this memory error and it would be nice > >> if I could do this. > > > > No, but it can do better: suspend the process and automatically start > > your debugger. Use the --db-attach=yes option. > > > >> Also, I am having a hard time deciphering this message, can anyone > >> please give me insight on what this error means? I've tried Google and > >> I had no luck :( > > [snip] > >> 1. ==20770== Invalid read of size 8 > >> 2. ==20770== at 0x662CBB: PacketPool::removePacket(Packet*) > > > > It means a variable, of width 8 (e.g. a double, long on amd64, etc.) > > is being read from yet is not valid. `Read' probably means it's an > > rvalue. `Invalid' implies the address is bad. IIUC, memory is invalid > > by default, marked valid when you assign to it, marked invalid when you > > delete/free it. There's a bit in the memcheck manual about 'shadow > > bits' and how they are used to track validity, IIRC. > > > > -tom |