|
From: Robert W. <rj...@du...> - 2005-06-02 04:57:56
|
> Invalid read of size 4 >=20 > Ok, as far as I understand this a read of size 4 is going outside of vali= d memory (be it stack or malloc'd memory) >=20 > Address 0x1BB4C834 is 260 bytes inside a block of size 764 alloc'd >=20 > So, valgrind goes on to tell me that this is WELL inside the block of 764= bytes allocated... 260 + 4 =3D=3D 264 < 764, it seems to be well inside th= e boundaries > of the allocated memory space. >=20 > I have the same output using both valgrind 2.2.0 and 2.4.0 >=20 > =3D=3D21823=3D=3D Invalid read of size 4 > =3D=3D21823=3D=3D at 0x1BA5BEA1: swapcontext (in /lib/libc-2.3.4.so) > =3D=3D21823=3D=3D Address 0x1BB4C834 is 260 bytes inside a block of si= ze 764 alloc'd > =3D=3D21823=3D=3D at 0x1B905C2C: malloc (vg_replace_malloc.c:131) > =3D=3D21823=3D=3D by 0x1B90E827: __pth_tcb_alloc (in /home/chatgris/= code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) > =3D=3D21823=3D=3D by 0x1B910E0F: pth_spawn (in /home/chatgris/code/u= niversity/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) > =3D=3D21823=3D=3D by 0x80489FE: main (in /home/chatgris/code/univers= ity/USRA/S05/cspdebug/a.out) >=20 > Any help understanding this output would be appreciated. If I were to guess, I'd suspect the swapcontext. I bet what's happening is that you've got multiple stacks allocated relatively close to each other (within 2MB of each other) and when you do a swapcontext to swap them around, Valgrind can't tell that the new one is a completely different stack, so it marks the space between the new %esp and the old %esp as invalid. Things go downhill from there. The reason why I spotted this is because we were having the exact same problem at work recently with a user-land thread package that used swapcontext. I wrote this patch for Valgrind to get around it: http://www.durables.org/~rjwalsh/software/valgrind/11-stack.diff This should apply cleanly to the SVN head. When you allocate a stack, register it with Valgrind by calling VALGRIND_STACK_REGISTER. Look in the test case in corecheck/tests/stack_changes.c for an example that uses swapcontext. This is for the 2.4 tree only. I haven't been able to get this working cleanly with the 3.0 tree yet, but I may have a little time to get it running over the weekend. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Joshua Moore-O. <jo...@ch...> - 2005-06-02 19:29:54
|
On June 2, 2005 04:57 am, Robert Walsh wrote: > > Invalid read of size 4 > > > > Ok, as far as I understand this a read of size 4 is going outside of valid memory (be it stack or malloc'd memory) > > > > Address 0x1BB4C834 is 260 bytes inside a block of size 764 alloc'd > > > > So, valgrind goes on to tell me that this is WELL inside the block of 764 bytes allocated... 260 + 4 == 264 < 764, it seems to be well inside the boundaries > > of the allocated memory space. > > > > I have the same output using both valgrind 2.2.0 and 2.4.0 > > > > ==21823== Invalid read of size 4 > > ==21823== at 0x1BA5BEA1: swapcontext (in /lib/libc-2.3.4.so) > > ==21823== Address 0x1BB4C834 is 260 bytes inside a block of size 764 alloc'd > > ==21823== at 0x1B905C2C: malloc (vg_replace_malloc.c:131) > > ==21823== by 0x1B90E827: __pth_tcb_alloc (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) > > ==21823== by 0x1B910E0F: pth_spawn (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) > > ==21823== by 0x80489FE: main (in /home/chatgris/code/university/USRA/S05/cspdebug/a.out) > > > > Any help understanding this output would be appreciated. > > If I were to guess, I'd suspect the swapcontext. I get similar errors that aren't swapcontext... for example ==21823== Invalid read of size 4 ==21823== at 0x1B910DA5: pth_spawn_trampoline (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) ==21823== Address 0x1BB4CA00 is 720 bytes inside a block of size 764 alloc'd ==21823== at 0x1B905C2C: malloc (vg_replace_malloc.c:131) ==21823== by 0x1B90E827: __pth_tcb_alloc (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) ==21823== by 0x1B910E0F: pth_spawn (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) ==21823== by 0x80489FE: main (in /home/chatgris/code/university/USRA/S05/cspdebug/a.out) arg is null ==21823== ==21823== Invalid read of size 4 ==21823== at 0x1B9121D2: pth_key_getdata (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) ==21823== Address 0x1BB4CA10 is 736 bytes inside a block of size 764 alloc'd ==21823== at 0x1B905C2C: malloc (vg_replace_malloc.c:131) ==21823== by 0x1B90E827: __pth_tcb_alloc (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) ==21823== by 0x1B910E0F: pth_spawn (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) ==21823== by 0x80489FE: main (in /home/chatgris/code/university/USRA/S05/cspdebug/a.out) ==21823== ==21823== Invalid read of size 4 ==21823== at 0x1B91210B: pth_key_setdata (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) ==21823== Address 0x1BB4CA10 is 736 bytes inside a block of size 764 alloc'd ==21823== at 0x1B905C2C: malloc (vg_replace_malloc.c:131) ==21823== by 0x1B90E827: __pth_tcb_alloc (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) ==21823== by 0x1B910E0F: pth_spawn (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) ==21823== by 0x80489FE: main (in /home/chatgris/code/university/USRA/S05/cspdebug/a.out) > I bet what's happening > is that you've got multiple stacks allocated relatively close to each > other (within 2MB of each other) and when you do a swapcontext to swap > them around, Valgrind can't tell that the new one is a completely > different stack, so it marks the space between the new %esp and the old > %esp as invalid. Things go downhill from there. > > The reason why I spotted this is because we were having the exact same > problem at work recently with a user-land thread package that used > swapcontext. I wrote this patch for Valgrind to get around it: What thread package were you using might I ask? > > http://www.durables.org/~rjwalsh/software/valgrind/11-stack.diff > > This should apply cleanly to the SVN head. When you allocate a stack, > register it with Valgrind by calling VALGRIND_STACK_REGISTER. Look in > the test case in corecheck/tests/stack_changes.c for an example that > uses swapcontext. Interesting.. I had found a very simple example of pure swapcontext and it didn't trigger and valgrind errors, I can send you a copy if you are interested. > > This is for the 2.4 tree only. I haven't been able to get this working > cleanly with the 3.0 tree yet, but I may have a little time to get it > running over the weekend. Thanks, I'll take a look at it. > > Regards, > Robert. > Thanks, Joshua Moore-Oliva |
|
From: Robert W. <rj...@du...> - 2005-06-02 19:54:52
|
> > If I were to guess, I'd suspect the swapcontext. > > I get similar errors that aren't swapcontext... for example > > ==21823== Invalid read of size 4 > ==21823== at 0x1B910DA5: pth_spawn_trampoline (in /home/chatgris/code/university/USRA/S05/pth-2.0.0-install-pthread/lib/libpth.so.20.0.20) I bet pth is swapping the stack behind your back here. > What thread package were you using might I ask? A proprietary coroutine library we developed at work. Unfortunately, I cannot release it. > Interesting.. I had found a very simple example of pure swapcontext and > it didn't trigger and valgrind errors, I can send you a copy if you are > interested. Well, it's only going to happen if the stack change delta is less than 2MB. It may not be the case in that particular circumstance. Run valgrind with -v to make it more verbose and see if it reports any stack changes. Regards, Robert. |
|
From: Joshua Moore-O. <jo...@ch...> - 2005-06-02 19:42:49
|
> I wrote this patch for Valgrind to get around it: > > http://www.durables.org/~rjwalsh/software/valgrind/11-stack.diff The url is not found... is there anywhere else I can get it? Thanks, Josh. |
|
From: Robert W. <rj...@du...> - 2005-06-02 19:47:45
|
On Thu, 2005-06-02 at 15:41 +0000, Joshua Moore-Oliva wrote: > > I wrote this patch for Valgrind to get around it: > > > > http://www.durables.org/~rjwalsh/software/valgrind/11-stack.diff > > The url is not found... is there anywhere else I can get it? Sorry - I sent out an email to the developers list with the new URL on it. Just go to: http://www.durables.org/~rjwalsh/software/valgrind and follow the links. Regards, Robert. |
|
From: Joshua Moore-O. <jo...@ch...> - 2005-06-02 20:15:01
|
> This should apply cleanly to the SVN head. When you allocate a stack, > register it with Valgrind by calling VALGRIND_STACK_REGISTER. Look in > the test case in corecheck/tests/stack_changes.c for an example that > uses swapcontext. I looked at the stack_changes.c and I see the register.. how do I go about= deleting or resizing the stack? =46rom your instructions I see this as well... "Tell Valgrind about a new stack by using the id =3D VALGRIND_STACK_NEW(sta= rt, end) client request. This marks memory between start and end as a stack= and returns a stack identifier." Which doesn't seem to mesh with the example in stack_changes.c... Which AP= I should I be using? Thanks Josh |
|
From: Robert W. <rj...@du...> - 2005-06-02 20:23:22
|
> > This should apply cleanly to the SVN head. When you allocate a stack, > > register it with Valgrind by calling VALGRIND_STACK_REGISTER. Look in > > the test case in corecheck/tests/stack_changes.c for an example that > > uses swapcontext. > > I looked at the stack_changes.c and I see the register.. how do I go > about deleting or resizing the stack? To remove a stack use VALGRIND_STACK_DEREGISTER(id). To change a stack use VALGRIND_STACK_CHANGE(id, newstart, newend). > >From your instructions I see this as well... > > "Tell Valgrind about a new stack by using the id = VALGRIND_STACK_NEW(start, end) > client request. This marks memory between start and end as a stack and returns a > stack identifier." Oops. I modified the patch to update the names of the client requests, but forgot to update the web page. > Which doesn't seem to mesh with the example in stack_changes.c... > Which API should I be using? The one in stack_changes.c is correct. The web page is updated now, too. Regards, Robert. |
|
From: Jeremy F. <je...@go...> - 2005-06-02 20:27:05
|
Robert Walsh wrote:
>If I were to guess, I'd suspect the swapcontext. I bet what's happening
>is that you've got multiple stacks allocated relatively close to each
>other (within 2MB of each other) and when you do a swapcontext to swap
>them around, Valgrind can't tell that the new one is a completely
>different stack, so it marks the space between the new %esp and the old
>%esp as invalid. Things go downhill from there.
>
>
Oh, yeah, I knew the swapcontext should have rung a bell. This seems
like the right explanation.
J
|