Another plea for advice... When running under valgrind, all--or nearly all--the memcheck error reports tell me that the address of the invalid access is on the stack, but it isn't. The program does call swapcontext to change its stack, but it also makes the appropriate client request to inform valgrind of this fact. ==6868== Invalid read of size 4 ==6868== at 0x66FBF0: ifvlan_send_intf (ifvlan.c:618) ==6868== Address 0x1a2e9108 is on thread 1's stack The same program is unable to properly process signals, with errors like this: ==6868== Can't extend stack to 0x55FF7B0 during signal delivery for thread 1: ==6868== no stack segment This is valgrind 3.3.1 and Linux 2.4.21. Thanks for reading, -m |
|
From: Michael R.
|
Both of the previous two problems I wrote about (valgrind crash while delivering a fatal signal and reports that things that were on the heap were on the stack) are eliminated when my program no longer switches stacks during startup. I've confirmed that I'm calling VALGRIND_STACK_REGISTER correctly. Has anyone else experienced a similar problem? |
|
From: John R.
|
Michael Rosellini wrote:
> Both of the previous two problems I wrote about (valgrind crash while delivering a fatal signal and reports that things that were on the heap were on the stack) are eliminated when my program no longer switches stacks during startup. I've confirmed that I'm calling VALGRIND_STACK_REGISTER correctly. Has anyone else experienced a similar problem?
See my postings to [valgrind-developers] in 2008 regarding patches for
valgrind to work on UserModeLinux (UML) and WINE. Some of them were related
to stacks. In particular, if the current actual stack pointer is outside
the bounds where coregrind thinks it ought to be, then my experience was
that coregrind had difficulty. This may not be the same as what you see,
but it helped me.
For instance, this message of 07/09/2008: [There are others, too.]
[Valgrind-developers] (14/14) vgsvn+wine-stacktrace.patch succeed when MSVC FramePointerOmitted
--- valgrind-svn/coregrind/m_stacktrace.c.orig 2008-07-06 13:44:21.000000000 -0700
+++ valgrind-svn/coregrind/m_stacktrace.c 2008-07-02 21:25:28.000000000 -0700
[snip]
@@ -439,6 +448,13 @@
Addr stack_lowest_word = 0;
# if defined(VGP_x86_linux)
+ if (VG_(threads)[tid].client_stack_szB <= (stack_highest_word - sp)) {
+ /* sp escaped its bounds. The application did not tell us
+ * about switching stacks, and we did not notice until now.
+ * Use something plausible.
+ */
+ stack_highest_word = 200*1024 + sp;
+ }
/* Nasty little hack to deal with syscalls - if libc is using its
_dl_sysinfo_int80 function for syscalls (the TLS version does),
then ip will always appear to be in that function when doing a
--
|
|
From: Nicholas N. <nj...@cs...> - 2008-11-18 06:59:57
|
On Mon, 17 Nov 2008, Michael Rosellini wrote: > Both of the previous two problems I wrote about (valgrind crash while > delivering a fatal signal and reports that things that were on the heap > were on the stack) are eliminated when my program no longer switches > stacks during startup. I've confirmed that I'm calling > VALGRIND_STACK_REGISTER correctly. Has anyone else experienced a similar > problem? I think the stack registration stuff is a bit buggy, but I don't recall the details right now. I think people must not use it very much. Nick |
|
From: Tom H. <to...@co...> - 2008-11-18 08:33:29
|
Nicholas Nethercote wrote: > On Mon, 17 Nov 2008, Michael Rosellini wrote: > >> Both of the previous two problems I wrote about (valgrind crash while >> delivering a fatal signal and reports that things that were on the heap >> were on the stack) are eliminated when my program no longer switches >> stacks during startup. I've confirmed that I'm calling >> VALGRIND_STACK_REGISTER correctly. Has anyone else experienced a similar >> problem? > > I think the stack registration stuff is a bit buggy, but I don't recall the > details right now. I think people must not use it very much. It's rubbish, and needs a complete ground up rework rather than band aid patches. IIRC there are at least two different ideas internally of what the current stack is and only one of those pays attention to the user stack registration stuff. In fact the user stack registration stuff does very little, and much less than most users probably expect when they use it. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Julian S. <js...@ac...> - 2008-11-18 10:41:35
|
On Tuesday 18 November 2008, Tom Hughes wrote: > Nicholas Nethercote wrote: > > On Mon, 17 Nov 2008, Michael Rosellini wrote: > >> Both of the previous two problems I wrote about (valgrind crash while > >> delivering a fatal signal and reports that things that were on the heap > >> were on the stack) are eliminated when my program no longer switches > >> stacks during startup. I've confirmed that I'm calling > >> VALGRIND_STACK_REGISTER correctly. Has anyone else experienced a > >> similar problem? > > > > I think the stack registration stuff is a bit buggy, but I don't recall > > the details right now. I think people must not use it very much. > > It's rubbish, and needs a complete ground up rework rather than band aid > patches. IIRC there are at least two different ideas internally of what > the current stack is and only one of those pays attention to the user > stack registration stuff. I agree. I never really understood it, and from what I remember from looking at it in the distant past, it's conceptually like swiss cheese -- full of holes. The relationship to stack unwinding should also be considered. At the moment the unwinder can segfault if a corrupted stack takes it into a non-mapped area. This ought to be fixed, although perhaps that's more a question of integration with the address space manager: what the unwinder really needs is a very fast way to ask whether a page is mapped or not; and simply stop if the page isn't mapped. J |
|
From: Tom H. <to...@co...> - 2008-11-18 10:49:37
Attachments:
valgrind-isreadable.patch
|
Julian Seward wrote: > On Tuesday 18 November 2008, Tom Hughes wrote: > >> It's rubbish, and needs a complete ground up rework rather than band aid >> patches. IIRC there are at least two different ideas internally of what >> the current stack is and only one of those pays attention to the user >> stack registration stuff. > > I agree. I never really understood it, and from what I remember from > looking at it in the distant past, it's conceptually like swiss cheese > -- full of holes. > > The relationship to stack unwinding should also be considered. Absolutely, and that's part of the problem that the stack unwinder doesn't take the user registered stacks into account IIRC. Plus the initial thread stacks (to the extent we can determine them at least) aren't registered with the stack manager, the the thread state attempts to track the current stack but doesn't synchronise that at all well with the stack manager. > At the moment the unwinder can segfault if a corrupted stack takes > it into a non-mapped area. This ought to be fixed, although perhaps > that's more a question of integration with the address space manager: > what the unwinder really needs is a very fast way to ask whether a > page is mapped or not; and simply stop if the page isn't mapped. I wrote a patch to do just that once actually... I never committed it though, possibly because I thought we should really have a better idea of where the stack is first and then just use an address space check as an emergency last ditch check. The patch is attached anyway... Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |