leekillough
commented
4 months ago I have reduced the test case by making data as small as necessary, and eliminated the loop:
[[gnu::noipa]] void foo() {
volatile char data[81];
data[2] = '\0';
}
int main( int argc, char** argv ) {
foo();
return argv[0][0];
}The assignment to data[2] apparently corrupts argv[0], making the return argv[0][0] dereference a nullptr.
I looked at the assembly code, and it looks mostly correct, although it only allocates 80 bytes for data instead of 81, although that shouldn't affect the data[2] assignment, and might be making sure sp is aligned to 16 bytes:
00000000000101b6 <foo()>:
101b6: 715d add sp,sp,-80
101b8: 00010123 sb zero,2(sp)
101bc: 6161 add sp,sp,80
101be: 8082 ret
0000000000010106 <main>:
10106: 1141 add sp,sp,-16
10108: e022 sd s0,0(sp)
1010a: e406 sd ra,8(sp)
1010c: 842e mv s0,a1
1010e: 0a8000ef jal 101b6 <foo()>
10112: 601c ld a5,0(s0)
10114: 60a2 ld ra,8(sp)
10116: 6402 ld s0,0(sp)
10118: 0007c503 lbu a0,0(a5)
1011c: 0141 add sp,sp,16
1011e: 8082 retWhen I change the declaration to data[82], the compiler completely changes the stack allocation of data to the next 16 byte stack allocation, and makes the assignment of data[2] look strange:
[[gnu::noipa]] void foo() {
volatile char data[82];
data[2] = '\0';
}
int main( int argc, char** argv ) {
foo();
return argv[0][0];
}00000000000101b6 <foo()>:
101b6: 711d add sp,sp,-96
101b8: 00010523 sb zero,10(sp)
101bc: 6125 add sp,sp,96
101be: 8082 ret0000000000010106 <main>:
10106: 1141 add sp,sp,-16
10108: e022 sd s0,0(sp)
1010a: e406 sd ra,8(sp)
1010c: 842e mv s0,a1
1010e: 0a8000ef jal 101b6 <foo()>
10112: 601c ld a5,0(s0)
10114: 60a2 ld ra,8(sp)
10116: 6402 ld s0,0(sp)
10118: 0007c503 lbu a0,0(a5)
1011c: 0141 add sp,sp,16
1011e: 8082 retI will try to find the physical address of argv[0] in the simulator, and set up watchpoints to catch its corruption.
ldalessa
Describe the bug
When I allocate and initialize a small
charbuffer on the stack it seems to be corrupting memory, in particular theargvstate. My understanding is that_STACK_SIZE_is1MBso I don't think that's the problem.To Reproduce
SST stuff
REV stuff (configured with
-DCMAKE_CXX_COMPILER=mpic++ -DCMAKE_BUILD_TYPE=Release).Test program.
volatileto prevent the loop from being removed,noipato prevent the call tofoofrom being removed, I split it into a functionfooto make it easier for me to look at the asm, but that doesn't impact the bug as long as the loop isn't removed by the dead-code passes.C++ compiler stuff, aggressive flags to minimize produced asm (flags don't matter).
Output asm
I'm using the
rev-model-options-config.pyprovided inrev/test.Additional context
I have tried rev's Debug, RelWithDebInfo, Release, and default builds and this doesn't matter. I have tried building Rev with just
g++instead of through thempic++wrapper and that doesn't matter. The size of the buffer does matter, if I drop down into the 190s it won't fail, depending on the build that I'm using, but 256 bytes consistently failed.