From: Chris F. <cf...@gm...> - 2012-09-24 18:16:06
|
On Mon, Sep 24, 2012 at 7:06 AM, Julian Seward <js...@ac...> wrote: > On Monday, September 24, 2012, Tom Hughes wrote: >> > ==16432== Invalid read of size 8 >> > ==16432== at 0x43319E: trampoline() (thread.cc:134) >> > ==16432== Address 0x646b5d8 is 56 bytes inside a block of size 72 >> > alloc'd ==16432== at 0x4C285A4: operator new(unsigned long) >> > (vg_replace_malloc.c:298) ==16432== by 0x432EFF: thread_new(void >> > (*)(void*, void*, void*), void*, void*, void*, unsigned long, int) >> > (thread.cc:142) >> > [ snip internal stuff ] >> > ==16432== by 0x4083AF: main (main.cc:210) >> > >> > If it's relevant, this is inside a little >> > userspace-cooperative-threads package I wrote and the code is running >> > on a malloc()'d stack. >> >> At a guess you're reading below the stack pointer. >> >> Assuming that the block it is complaining about is the block that your >> user space thread is using as stack what is happening is that when the >> stack is popped valgrind will mark the stack below the stack pointer as >> invalid, and then if you try and read it you will get that error. > > The block is only 72 bytes long, though, which seems implausibly small > for a stack. > > J Yes, the 72-byte block is a 'struct' describing the thread and the invalid reads are fields in the struct. Question: will "Invalid read of size N" occur if the dataflow tracking thinks that the address itself is invalid, or does it only occur if the address being accessed is not fully enclosed by an alloc'd/stack'd block or global data? (If the latter, why would the message appear if base address + access size <= end of block, as is seen here?) I gather that it's separate from an "undefined value" message which would occur if the value *at* the address had not been initialized... Here's a reduced test case for anyone who wants to look further: http://atom.ece.cmu.edu/vgerror/ (tar.bz2 within there). g++ 4.6.3 on Ubuntu 12.04, x86-64, valgrind 3.8.1 and 3.7.0 tested. Thanks! Chris |