Re: How to debug a corrupted stack

On 8 Aug 2008, at 09:04, Sean McBride wrote: Gerriet M. Denkmann ([EMAIL PROTECTED]) on 2008-8-8 9:49 PM said: some_type a; NSValue *data = [ NSValue value: &a withObjCType: @encode (some_type) ]; followed by: some_type b; [ data getValue: &b ]; is unsafe, da

Re: How to debug a corrupted stack

On Aug 7, 2008, at 9:49 PM, Gerriet M. Denkmann wrote: Or does anyone have a better idea? Define your own struct or Objective-C class that has the same members as UTCDateTime. Copy the values from a UTCDateTime to your struct or class. Encode/Decode your struct or class from NSValue. W

Re: How to debug a corrupted stack

Gerriet M. Denkmann ([EMAIL PROTECTED]) on 2008-8-8 9:49 PM said: > some_type a; > NSValue *data = [ NSValue value: &a withObjCType: @encode >(some_type) ]; >followed by: > some_type b; > [ data getValue: &b ]; >is unsafe, dangerous and strictly to be avoided - especially

Re: How to debug a corrupted stack

On 8 Aug 2008, at 01:59, Johannes Fortmann <[EMAIL PROTECTED]> wrote: The problem here is that UTCDateTime is defined with #pragma pack 2 in effect. That means the compiler packs with an alignment of 2, so the whole structure has 8 bytes. The proper alignment (4) results in 12 bytes. Since th

Re: How to debug a corrupted stack

The problem here is that UTCDateTime is defined with #pragma pack 2 in effect. That means the compiler packs with an alignment of 2, so the whole structure has 8 bytes. The proper alignment (4) results in 12 bytes. Since there's nothing in the @encode'd information specifying the non-standa

Re: How to debug a corrupted stack

On Thu, Aug 7, 2008 at 11:28 AM, Gerriet M. Denkmann <[EMAIL PROTECTED]> wrote: > Maybe someone would want to check this on Leopard. File a bug (http://bugreport.apple.com). That's the quickest way to make sure that 1) if it's a problem, it gets fixed or 2) if it's not a problem someone from Appl

Re: How to debug a corrupted stack

On 6 Aug 2008, at 21:56, Shawn Erickson wrote: On Tue, Aug 5, 2008 at 7:51 PM, Gerriet M. Denkmann <[EMAIL PROTECTED]> wrote: I have a document based app which works perfectly with -O0 or -O1 but crashes with -O2 or higher. When the crash occurs the debugger comes up and says: "Previous frame

Re: How to debug a corrupted stack

On 7 Aug 2008, at 01:16, Sean McBride wrote: On 8/6/08 9:51 AM, Gerriet M. Denkmann said: So it is kind of difficult to see where and why the stack gets corrupted. Have you tried 'stack canaries'? I have not. Seems this

Re: How to debug a corrupted stack

On 8/6/08 9:51 AM, Gerriet M. Denkmann said: >So it is kind of difficult to see where and why the stack gets >corrupted. Have you tried 'stack canaries'? On 8/6/08 7:59 PM, Gerriet M. Denkmann said: >If someone wants to chec

Re: How to debug a corrupted stack

On Tue, Aug 5, 2008 at 7:51 PM, Gerriet M. Denkmann <[EMAIL PROTECTED]> wrote: > I have a document based app which works perfectly with -O0 or -O1 but > crashes with -O2 or higher. > > When the crash occurs the debugger comes up and says: "Previous frame > identical to this frame (corrupt stack?)"

Re: How to debug a corrupted stack

On 6 Aug 2008, at 11:14, Ken Thomases wrote: On Aug 5, 2008, at 9:51 PM, Gerriet M. Denkmann wrote: I have a document based app which works perfectly with -O0 or -O1 but crashes with -O2 or higher. When the crash occurs the debugger comes up and says: "Previous frame identical to this fr

Re: How to debug a corrupted stack

On Aug 5, 2008, at 9:51 PM, Gerriet M. Denkmann wrote: I have a document based app which works perfectly with -O0 or -O1 but crashes with -O2 or higher. When the crash occurs the debugger comes up and says: "Previous frame identical to this frame (corrupt stack?)" When I try to step throu

How to debug a corrupted stack

I have a document based app which works perfectly with -O0 or -O1 but crashes with -O2 or higher. When the crash occurs the debugger comes up and says: "Previous frame identical to this frame (corrupt stack?)" When I try to step through the function (which is kind of difficult, as the opt