Re: C local auto-initialized?
Re: C local auto-initialized?
- Subject: Re: C local auto-initialized?
- From: alex <email@hidden>
- Date: Thu, 20 Sep 2007 18:29:08 -0700
Perhaps you can substitute a debug allocator library that overrides new/delete/malloc/free. On other platforms these libraries come for free. They cause memory that was once used and freed to be set to 0xCC, or some other value that is easily detected. They also set the stack to bogus values for easy detection.
This approach coupled with a bit of 'tricky stack manipulation' will get you tons of uninitialized values other than 0 for your autos. With just alittle debug assembler glue you can 'wipe' your current stack will help tremendously. I can't tell you how many times this technique has saved me weeks of debugging intermittent bugs.
The problem here is that while this is an important thing to teach, the best way to code against it is to force your allocator to initialize your variables to bogus values with the hopes of catching these accesses to uninitialized memory. Better yet, _always_ initialize your variables (unless you are in a tight loop of course :))
Best of luck,
a
At 4:02 PM -0500 9/20/07, Fritz Anderson wrote:
>For a teaching exercise, I need to demonstrate debugging an uninitialized variable. It seems to be hard to make a variable uninitialized in the Debug configuration.
>
>Consider the following code:
>
>//==============================
>void partial(void)
>{
>#if STRANGENESS
> double sumY, sumY2;
>#else
> double sumY2, sumY;
>#endif
> // [1]: sumY2 is garbage
> double y = 4.0;
> sumY2 += y * y; // [2]: sumY2 used uninitialized
> printf("sumY2 = %f", sumY2);
>#if STRANGENESS
> // [3a]: sumY2 is nonetheless 16.0
>#else
> // [3b]: sumY2 is garbage plus 16.0
>#endif
>}
>//==============================
>
>
>Notice that sumY2 is used without being initialized. In both configurations, it contains garbage after [1].
>
>If sumY2 is the first variable declared in the function, the garbage value propagates into the sum. [3b], STRANGENESS == 0
>
>If sumY2 is not the first variable declared, the garbage value does not propagate. [3a], STRANGENESS == 1
>
>It's hard to see how the generated code would "know" to zero out the initial sum, nor why it would do it inconsistently if it did know.
>
>The strangeness disappears when the configuration is switched from Debug to Release. PPC or Intel doesn't matter. Running with or without the debugger doesn't matter.
>
>There's nothing in the disassembly that's obvious. In my much-longer original code, sumY2 is at -48(ëp), and there is no reference to it (and therefore no initialization) until the addition:
>
>LM10: ; sumY2 += y * y;
> movsd -96(ëp), %xmm1
> movsd -96(ëp), %xmm0 ; y is at -96(ëp)
> mulsd %xmm0, %xmm1 ; y * y
> movsd -48(ëp), %xmm0 ; sumY2 is at -48(ëp)
> addsd %xmm1, %xmm0 ; product + sumY2
> movsd %xmm0, -48(ëp) ; sum -> sumY2
>
>Can anyone comment? Is there a way to demonstrate the "correct" (garbage-propagating) behavior without blatantly placing the garbage variable at the head of the block?
>
>Xcode 2.4.1 and later.
>
> - F
>
>_______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Xcode-users mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>
>This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden