|
From: Chris F. <cf...@gm...> - 2012-09-23 21:10:01
|
Hi all, I'm getting a perplexing error message with Valgrind. I get an "invalid read of size 8", but the address is inside an allocated block (and the access size doesn't go out-of-bounds). The access goes through fine but I'm debugging a segfault much later in execution (the reason I started using Valgrind just now and saw a bunch of these errors). I'm wondering if maybe there's some other reason I would see this message: ==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. Any suggestions? Thanks! Chris Fallin |
|
From: Tom H. <to...@co...> - 2012-09-23 22:05:50
|
On 23/09/12 22:09, Chris Fallin wrote: > I'm getting a perplexing error message with Valgrind. I get an > "invalid read of size 8", but the address is inside an allocated block > (and the access size doesn't go out-of-bounds). The access goes > through fine but I'm debugging a segfault much later in execution (the > reason I started using Valgrind just now and saw a bunch of these > errors). I'm wondering if maybe there's some other reason I would see > this message: > > > ==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. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Julian S. <js...@ac...> - 2012-09-24 11:07:17
|
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 |
|
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 |
|
From: Tom H. <to...@co...> - 2012-09-24 18:26:41
|
On 24/09/12 19:15, Chris Fallin wrote: > 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... It sounds like you're a bit confused about valgrind works... There is no dataflow tracking, just tracking of which bytes of memory are addressable and which bits are defined. So when a block is allocated with malloc it will be marked as addressable but not defined and it wouldn't normally be marked unaddressable until it was freed. I think the only real exception to that, other that for the stack as described before, is where a client request is used to explicitly mark a piece of memory as unaddressable. Reading a word which overlapped the end of a block would certainly produce that error, but that isn't what is happening here as you say. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |