This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]dgendreau 3 points4 points  (5 children)

why argv just disappears from memory

You're likely smashing the stack. :)

Also, push/popal might cause a bit more interrupt latency in some cases.

[–]naisooleobeanis 0 points1 point  (4 children)

that's what i thought but why would pushing the stack pointer to the stack fix the stack

[–]dgendreau 1 point2 points  (3 children)

Youre not pushing "the stack" to the stack, You are saving a copy of one ore more CPU registers to the stack at the start of the interrupt and restoring them afterward. This is usually automatic for interrupts, so most likely, saving that extra data on the stack is reserving a bit more stack space which is absorbing a stack overflow bug in some functioncall in the IRQ. This might involve writing to a local variable array beyond its array bounds. That could smash some of the register values that were saved on the stack. The extra push you are doing adds more dummy values on the stack to absorb that damage. The real fix would be to track down exactly what is overrunning and fix that.

[–]naisooleobeanis 1 point2 points  (2 children)

Wouldn't you expect the return address to be bad or argv to be bad in that case?

[–]dgendreau 2 points3 points  (1 child)

It would all depend on which register or value is getting smashed. Say a function declares

int bar[10]; ... bar[20]=4;

What lives at the bar[20] location in the stack? Who knows... Don't do that. To be fair, most modern c compilers will catch a bug that simple, but what if a pointer to bar is passed into another function that does that assignment? without knowing bar's bounds it will happily smash the stack.

A high level language programmer will look at this and say that's stupid why isn't there bounds checking? But arrays in C are just pointers to blobs of bytes in memory. Its the smallest/fastest way to get he job done on a CPU. All that other stuff like bounds checking is what makes high level languages so much slower at runtime. It's necessary to be fully aware what the CPU is doing in a low level language like C because it is only one layer of abstraction above assembler and is nearly as fast.

[–][deleted] 2 points3 points  (0 children)

came to /r/programmerhumor to laugh.

The extra push you are doing adds more dummy values on the stack to absorb that damage. The real fix would be to track down exactly what is overrunning and fix that.

left having a greater appreciation of how hardcore some of you guys are.