__stack_chk_fail

[Sparky81]

For some reason, the compiler tries to find a function called __stack_chk_fail in src/text.c, even though it is never called in the actual code. This has been fixed only by a workaround, by making a "dummy function." If someone could explain this or give an actual fix for it, that would be great. This is medium priority, and there is no due date for a solution.

[swarley]

This would be fixed faster with a definition in _ASM_

__stack_chk_fail:
                            ret

Or at least I believe, it would also look much better.

[swarley]

Actually I may have fixed it in theory at least. We'll test this as soon as I can get home.

[FellowTraveler]

__stack_chk_fail is a protection mechanism that triggers when it's been detected that you are corrupting all over your stack.

The purpose of __stack_chk_fail is to kill your application as quickly as possible, once such corruption has started, in order to make it easier for you to get a stack trace and find out where things actually went wrong.

Without __stack_chk_fail, you will still crash eventually, or get corrupted data -- your bug isn't magically gone -- but instead of a useful stack trace, you'll get stuck with something like this:

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
#0 0x00f7aae8 in 0xf7aae8
#1 0x0051f3c4 in 0x51f3c4
#2 0x0051efe4 in 0x51efe4
#3 0x0051ed74 in 0x51ed74
#4 0x0051dec8 in 0x51dec8

Then you will sit there scratching your head in frustration and confusion until you Google around and find out that __stack_chk_fail is your friend, and that your actual bug is in your own code, somewhere before that point.

[swarley]

Yes however on a kernel this its not necessary, as seeing a register dump
is just as well. It had to be disabled with a command line flag
On May 26, 2012 10:38 AM, "FellowTraveler" <
reply@reply.github.com>
wrote:

__stack_chk_fail is a protection mechanism that triggers when it's been
detected that you are corrupting all over your stack.

The purpose of __stack_chk_fail is to kill your application as quickly as
possible, once such corruption has started, in order to make it easier for
you to get a stack trace and find out where things actually went wrong.

Without __stack_chk_fail, you will still crash eventually, or get
corrupted data -- your bug isn't magically gone -- but instead of a useful
stack trace, you'll get stuck with something like this:

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
#0 0x00f7aae8 in 0xf7aae8
#1 0x0051f3c4 in 0x51f3c4
#2 0x0051efe4 in 0x51efe4
#3 0x0051ed74 in 0x51ed74
#4 0x0051dec8 in 0x51dec8

Then you will sit there scratching your head in frustration and confusion
until you Google around and find out that __stack_chk_fail is your friend,
and that your actual bug is in your own code, somewhere before that point.

---

Reply to this email directly or view it on GitHub:
#1 (comment)