__stack_chk_fail?
-
Hello,
I'm writing an mp3 file renamer that uses the id3lib. Somewhere in the id3lib code my app crashes with SIGABRT when trying to return from a function* showing "__stack_chk_fail" in the debugger's stack trace pane. This happens when I use GCC 4.2 as compiler. When I use LLVM GCC 4.2 my application runs just fine. Neither clang nor GuardMalloc show any problems at compile- or runtime.
I'm using Xcode 3.2.5 on Mac OS 10.6.6.
Does someone have an idea what could be the problem here?
Thanks and regards,
Sebastian Mecklenburg
*bool Mp3Info::Parse(ID3_Reader& reader, size_t mp3size) to be precise _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (<Xcode-users...>)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/<xcode...>
This email sent to <xcode...> -
Le 14 févr. 2011 à 16:00, sebi a écrit :
> Hello,
>
> I'm writing an mp3 file renamer that uses the id3lib. Somewhere in the id3lib code my app crashes with SIGABRT when trying to return from a function* showing "__stack_chk_fail" in the debugger's stack trace pane. This happens when I use GCC 4.2 as compiler. When I use LLVM GCC 4.2 my application runs just fine. Neither clang nor GuardMalloc show any problems at compile- or runtime.
> I'm using Xcode 3.2.5 on Mac OS 10.6.6.
> Does someone have an idea what could be the problem here?
>
> Thanks and regards,
> Sebastian Mecklenburg
This is a stack corruption error. You're probably writing past the end of a stack buffer and corrupt your stack.
I'm not sure llvm-gcc 4.2 properly supports this feature (that would explain why it run fine when using llvm-gcc), or it may simply order variables on the stack in a way that prevent the overflow detection.
Anyway, you should check your function to find why the stack is corrupted when it returns.
-- Jean-Daniel -
GCC has an option to prevent "buffer overflow protection" you can use it with compiler option :
-fstack-protector / -fno-stack-protector
Le 14 févr. 2011 à 16:05, Jean-Daniel Dupas a écrit :
> Le 14 févr. 2011 à 16:00, sebi a écrit :
>
>> Hello,
>>
>> I'm writing an mp3 file renamer that uses the id3lib. Somewhere in the id3lib code my app crashes with SIGABRT when trying to return from a function* showing "__stack_chk_fail" in the debugger's stack trace pane. This happens when I use GCC 4.2 as compiler. When I use LLVM GCC 4.2 my application runs just fine. Neither clang nor GuardMalloc show any problems at compile- or runtime.
>> I'm using Xcode 3.2.5 on Mac OS 10.6.6.
>> Does someone have an idea what could be the problem here?
>>
>> Thanks and regards,
>> Sebastian Mecklenburg
>
> This is a stack corruption error. You're probably writing past the end of a stack buffer and corrupt your stack.
> I'm not sure llvm-gcc 4.2 properly supports this feature (that would explain why it run fine when using llvm-gcc), or it may simply order variables on the stack in a way that prevent the overflow detection.
> Anyway, you should check your function to find why the stack is corrupted when it returns.
>
>
> -- Jean-Daniel
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/xcode-users/<clawfr59...>
>
> This email sent to <clawfr59...>
-
It does not prevent buffer overflow, it generate check in each function to abort when one is detected.
This is exactly what append here, __stack_chk_fail is the call inserted by GCC to check the stack and abort if it is corrupted.
Le 14 févr. 2011 à 16:15, claw a écrit :
> GCC has an option to prevent "buffer overflow protection" you can use it with compiler option :
>
> -fstack-protector / -fno-stack-protector
>
>
> Le 14 févr. 2011 à 16:05, Jean-Daniel Dupas a écrit :
>
>> Le 14 févr. 2011 à 16:00, sebi a écrit :
>>
>>> Hello,
>>>
>>> I'm writing an mp3 file renamer that uses the id3lib. Somewhere in the id3lib code my app crashes with SIGABRT when trying to return from a function* showing "__stack_chk_fail" in the debugger's stack trace pane. This happens when I use GCC 4.2 as compiler. When I use LLVM GCC 4.2 my application runs just fine. Neither clang nor GuardMalloc show any problems at compile- or runtime.
>>> I'm using Xcode 3.2.5 on Mac OS 10.6.6.
>>> Does someone have an idea what could be the problem here?
>>>
>>> Thanks and regards,
>>> Sebastian Mecklenburg
>>
>> This is a stack corruption error. You're probably writing past the end of a stack buffer and corrupt your stack.
>> I'm not sure llvm-gcc 4.2 properly supports this feature (that would explain why it run fine when using llvm-gcc), or it may simply order variables on the stack in a way that prevent the overflow detection.
>> Anyway, you should check your function to find why the stack is corrupted when it returns.
>>
>>
>> -- Jean-Daniel
>>
>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list (<Xcode-users...>)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/xcode-users/<clawfr59...>
>>
>> This email sent to <clawfr59...>
>
-- Jean-Daniel -
so perhaps the check configuration contains wrong value, i found the following URL about how the stack checking is done
http://www.delorie.com/gnu/docs/gcc/gccint_124.html
Le 14 févr. 2011 à 16:19, Jean-Daniel Dupas a écrit :
> It does not prevent buffer overflow, it generate check in each function to abort when one is detected.
> This is exactly what append here, __stack_chk_fail is the call inserted by GCC to check the stack and abort if it is corrupted.
>
>
> Le 14 févr. 2011 à 16:15, claw a écrit :
>
>> GCC has an option to prevent "buffer overflow protection" you can use it with compiler option :
>>
>> -fstack-protector / -fno-stack-protector
>>
>>
>> Le 14 févr. 2011 à 16:05, Jean-Daniel Dupas a écrit :
>>
>>> Le 14 févr. 2011 à 16:00, sebi a écrit :
>>>
>>>> Hello,
>>>>
>>>> I'm writing an mp3 file renamer that uses the id3lib. Somewhere in the id3lib code my app crashes with SIGABRT when trying to return from a function* showing "__stack_chk_fail" in the debugger's stack trace pane. This happens when I use GCC 4.2 as compiler. When I use LLVM GCC 4.2 my application runs just fine. Neither clang nor GuardMalloc show any problems at compile- or runtime.
>>>> I'm using Xcode 3.2.5 on Mac OS 10.6.6.
>>>> Does someone have an idea what could be the problem here?
>>>>
>>>> Thanks and regards,
>>>> Sebastian Mecklenburg
>>>
>>> This is a stack corruption error. You're probably writing past the end of a stack buffer and corrupt your stack.
>>> I'm not sure llvm-gcc 4.2 properly supports this feature (that would explain why it run fine when using llvm-gcc), or it may simply order variables on the stack in a way that prevent the overflow detection.
>>> Anyway, you should check your function to find why the stack is corrupted when it returns.
>>>
>>>
>>> -- Jean-Daniel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Xcode-users mailing list (<Xcode-users...>)
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/xcode-users/<clawfr59...>
>>>
>>> This email sent to <clawfr59...>
>>
>
> -- Jean-Daniel
>
>
>
>
-
Le 14 févr. 2011 à 16:34, claw a écrit :
> so perhaps the check configuration contains wrong value, i found the following URL about how the stack checking is done
>
> http://www.delorie.com/gnu/docs/gcc/gccint_124.html
>
http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-
always-your-fault.html
>
> Le 14 févr. 2011 à 16:19, Jean-Daniel Dupas a écrit :
>
>> It does not prevent buffer overflow, it generate check in each function to abort when one is detected.
>> This is exactly what append here, __stack_chk_fail is the call inserted by GCC to check the stack and abort if it is corrupted.
>>
>>
>> Le 14 févr. 2011 à 16:15, claw a écrit :
>>
>>> GCC has an option to prevent "buffer overflow protection" you can use it with compiler option :
>>>
>>> -fstack-protector / -fno-stack-protector
>>>
>>>
>>> Le 14 févr. 2011 à 16:05, Jean-Daniel Dupas a écrit :
>>>
>>>> Le 14 févr. 2011 à 16:00, sebi a écrit :
>>>>
>>>>> Hello,
>>>>>
>>>>> I'm writing an mp3 file renamer that uses the id3lib. Somewhere in the id3lib code my app crashes with SIGABRT when trying to return from a function* showing "__stack_chk_fail" in the debugger's stack trace pane. This happens when I use GCC 4.2 as compiler. When I use LLVM GCC 4.2 my application runs just fine. Neither clang nor GuardMalloc show any problems at compile- or runtime.
>>>>> I'm using Xcode 3.2.5 on Mac OS 10.6.6.
>>>>> Does someone have an idea what could be the problem here?
>>>>>
>>>>> Thanks and regards,
>>>>> Sebastian Mecklenburg
>>>>
>>>> This is a stack corruption error. You're probably writing past the end of a stack buffer and corrupt your stack.
>>>> I'm not sure llvm-gcc 4.2 properly supports this feature (that would explain why it run fine when using llvm-gcc), or it may simply order variables on the stack in a way that prevent the overflow detection.
>>>> Anyway, you should check your function to find why the stack is corrupted when it returns.
>>>>
>>>>
>>>> -- Jean-Daniel
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Xcode-users mailing list (<Xcode-users...>)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/xcode-users/<clawfr59...>
>>>>
>>>> This email sent to <clawfr59...>
>>>
>>
>> -- Jean-Daniel
>>
>>
>>
>>
>
-- Jean-Daniel -
ok ok :)
Le 14 févr. 2011 à 16:47, Jean-Daniel Dupas a écrit :
>
> Le 14 févr. 2011 à 16:34, claw a écrit :
>
>> so perhaps the check configuration contains wrong value, i found the following URL about how the stack checking is done
>>
>> http://www.delorie.com/gnu/docs/gcc/gccint_124.html
>>
>
>
> http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-
always-your-fault.html
>
>
>
>>
>> Le 14 févr. 2011 à 16:19, Jean-Daniel Dupas a écrit :
>>
>>> It does not prevent buffer overflow, it generate check in each function to abort when one is detected.
>>> This is exactly what append here, __stack_chk_fail is the call inserted by GCC to check the stack and abort if it is corrupted.
>>>
>>>
>>> Le 14 févr. 2011 à 16:15, claw a écrit :
>>>
>>>> GCC has an option to prevent "buffer overflow protection" you can use it with compiler option :
>>>>
>>>> -fstack-protector / -fno-stack-protector
>>>>
>>>>
>>>> Le 14 févr. 2011 à 16:05, Jean-Daniel Dupas a écrit :
>>>>
>>>>> Le 14 févr. 2011 à 16:00, sebi a écrit :
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm writing an mp3 file renamer that uses the id3lib. Somewhere in the id3lib code my app crashes with SIGABRT when trying to return from a function* showing "__stack_chk_fail" in the debugger's stack trace pane. This happens when I use GCC 4.2 as compiler. When I use LLVM GCC 4.2 my application runs just fine. Neither clang nor GuardMalloc show any problems at compile- or runtime.
>>>>>> I'm using Xcode 3.2.5 on Mac OS 10.6.6.
>>>>>> Does someone have an idea what could be the problem here?
>>>>>>
>>>>>> Thanks and regards,
>>>>>> Sebastian Mecklenburg
>>>>>
>>>>> This is a stack corruption error. You're probably writing past the end of a stack buffer and corrupt your stack.
>>>>> I'm not sure llvm-gcc 4.2 properly supports this feature (that would explain why it run fine when using llvm-gcc), or it may simply order variables on the stack in a way that prevent the overflow detection.
>>>>> Anyway, you should check your function to find why the stack is corrupted when it returns.
>>>>>
>>>>>
>>>>> -- Jean-Daniel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Xcode-users mailing list (<Xcode-users...>)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/xcode-users/<clawfr59...>
>>>>>
>>>>> This email sent to <clawfr59...>
>>>>
>>>
>>> -- Jean-Daniel
>>>
>>>
>>>
>>>
>>
>
> -- Jean-Daniel
>
>
>
>
-
hehe, agreed :-)
unfortunately this is some old 3rd party code and I'm not in the mood to look for stack corrupting code there. I hoped there was some simple solution but now I think it might be better to use some more recent id3 library instead.
thanks and regards,
sebastian mecklenburg
On 14.02.2011, at 16:47, Jean-Daniel Dupas wrote:
>
> Le 14 févr. 2011 à 16:34, claw a écrit :
>
>> so perhaps the check configuration contains wrong value, i found the following URL about how the stack checking is done
>>
>> http://www.delorie.com/gnu/docs/gcc/gccint_124.html
>>
>
>
> http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-
always-your-fault.html
>
>
>
>>
>> Le 14 févr. 2011 à 16:19, Jean-Daniel Dupas a écrit :
>>
>>> It does not prevent buffer overflow, it generate check in each function to abort when one is detected.
>>> This is exactly what append here, __stack_chk_fail is the call inserted by GCC to check the stack and abort if it is corrupted.
>>>
>>>
>>> Le 14 févr. 2011 à 16:15, claw a écrit :
>>>
>>>> GCC has an option to prevent "buffer overflow protection" you can use it with compiler option :
>>>>
>>>> -fstack-protector / -fno-stack-protector
>>>>
>>>>
>>>> Le 14 févr. 2011 à 16:05, Jean-Daniel Dupas a écrit :
>>>>
>>>>> Le 14 févr. 2011 à 16:00, sebi a écrit :
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm writing an mp3 file renamer that uses the id3lib. Somewhere in the id3lib code my app crashes with SIGABRT when trying to return from a function* showing "__stack_chk_fail" in the debugger's stack trace pane. This happens when I use GCC 4.2 as compiler. When I use LLVM GCC 4.2 my application runs just fine. Neither clang nor GuardMalloc show any problems at compile- or runtime.
>>>>>> I'm using Xcode 3.2.5 on Mac OS 10.6.6.
>>>>>> Does someone have an idea what could be the problem here?
>>>>>>
>>>>>> Thanks and regards,
>>>>>> Sebastian Mecklenburg
>>>>>
>>>>> This is a stack corruption error. You're probably writing past the end of a stack buffer and corrupt your stack.
>>>>> I'm not sure llvm-gcc 4.2 properly supports this feature (that would explain why it run fine when using llvm-gcc), or it may simply order variables on the stack in a way that prevent the overflow detection.
>>>>> Anyway, you should check your function to find why the stack is corrupted when it returns.
>>>>>
>>>>>
>>>>> -- Jean-Daniel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Xcode-users mailing list (<Xcode-users...>)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/xcode-users/<clawfr59...>
>>>>>
>>>>> This email sent to <clawfr59...>
>>>>
>>>
>>> -- Jean-Daniel
>>>
>>>
>>>
>>>
>>
>
> -- Jean-Daniel
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/xcode-users/<sebi...>
>
> This email sent to <sebi...>
>
