CODEWITHSUNDEEP
valgrindsegmentation-fault
BCH
BCH

Reputation: 31

"Bad permissions for mapped region at address" Valgrind error for memset

I am running into a problem that appears to be due to a stack overflow. When I run the application under Valgrind, I get the following errors:

Thread 75:
Invalid write of size 4
   at 0x833FBF6: <Class Name>::<Method Name>(short, short&) (<File Name>:692)
 Address 0x222d75c0 is on thread 75's stack

Process terminating with default action of signal 11 (SIGSEGV): dumping core
 Bad permissions for mapped region at address 0x222D6000
   at 0x4022BA3: memset (mc_replace_strmem.c:586)
   by 0x833FC80: <Class Name>::<Method Name>(short, short&) (<File Name>:708)

If I open the core file in gdb, go to frame 1 where the memset is being called, and do an "info registers", it shows that $esp = 0x222d5210 and $ebp = 0x222d75c8.

Doesn't that seem to indicate that the stack would include memory at addres 0x222D6000? If that's true, then why would we get the "Bad permissions" error?

The other odd thing is that line 692 of the source file is the very first line of the method (i.e., "void ::(short var1, short &var2)"). So, why would we get an invalid write at that point?

As I said, it seems to be a case of running out of stack space, but even if we use the "limit stacksize" command to increase the amount of allocated stack space, we still encounter the same problem.

I've been beating my head against the wall for several days trying to debug this problem. Any advice would be appreciated.

Upvotes: 2

Views: 3280

Answers (2)

BCH
BCH

Reputation: 31

It turns out that this problem was due to a stack overflow after all. I didn't realize that the code that spawned the thread that was causing the problem explicitly set the size of the stack to be used by the thread. That's why changing the value used by the "limit stacksize" command didn't make a difference. Once, I modified the code that set the stack size to increase the amount of memory allocated, the problem went away.

Upvotes: 1

phd
phd

Reputation: 3807

What you could do is to activate the Valgrind gdbserver, and attach using gdb+vgdb to your program running under Valgrind. You can then use various valgrind monitor commands to have more info about the problem. E.g. look again at the register values, use 'monitor v.info scheduler' to see the stack trace and the stack size, ...

Full list of monitor commands with memcheck+valgrind can be found at http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands and http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.valgrind-monitor-commands

Upvotes: 0

Related Questions