what is valgrind warning msg "client switching stacks"

Question

I see below warning msg "client switching stacks" when I run my program under valgrind. What does this warning trying to communicate? Is it something I need to bother? Or just to follow the advice of using --max-stackframe is enough?

root@e2term-alpha:/opt/e2# cat leak.out 
==49== Memcheck, a memory error detector
==49== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==49== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==49== Command: ./e2 -p config -f config.conf
==49== Parent PID: 27
==49== 
==49== Warning: client switching stacks?  SP change: 0xa1f6dc0 --> 0xa476ef8  -----> ???
==49==          to suppress, use: --max-stackframe=2621752 or greater
==49== Warning: client switching stacks?  SP change: 0xa9f7dc0 --> 0xac77ef8
==49==          to suppress, use: --max-stackframe=2621752 or greater
==49== Warning: client switching stacks?  SP change: 0xb1f8dc0 --> 0xb478ef8
==49==          to suppress, use: --max-stackframe=2621752 or greater
==49==          further instances of this message will not be shown.

Answer 1

First, what does "switching stacks" mean?

For a plain single threaded exe with no fancy control flow stuff, you just have one stack. Normally this starts at the top of memory and grows downwards. As you call functions and/or add more or larger local variables, the stack keeps growing.

When you have threads and fancy control flow then there can be an abrupt change to the stack pointer. Threads have their own stacks (but also separate PIDs so generally less of an issue). If you use setjmp/longjmp then there will be a stack switch at the longjmp call. C++ exception unwinding can cause pretty much all of the stack to unwind. If you use a signal handler with an alternate stack then again you can get a stack switch.

The problem is when you call a function that grows the stack in a big way (usually declaring a huge local array or using alloca for a very large stack allocation). Then Valgrind gets confused as to whether there has been some sort of stack switch or not.

If you don't use --max-stackframe then Valgrind will just continue but will not track the huge extra stack space. That is likely to cause problems like spurious errors.

My advice is to check your code to see if you really need to allocate so much on the stack. If you do really need it then use --max-stackframe.