__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...>
    >
previous month february 2011 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28            
Go to today