• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: C local auto-initialized? (persists)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C local auto-initialized? (persists)


  • Subject: Re: C local auto-initialized? (persists)
  • From: Fritz Anderson <email@hidden>
  • Date: Thu, 20 Sep 2007 17:15:27 -0500

On Sep 20, 2007, at 4:36 PM, Scott Ribe wrote:

Remember that when blocks are first allocated into your address space by the
VM system, they are zero'd as a security measure to prevent data from
leaking across process boundaries. This is not an uncommon scenario: a
variable that ought to be initialized to 0 isn't, and in light testing it's
always 0, but in use where the application is run for a long time it
eventually starts to get non-zero values. Not so much values on the stack
because the stack occupies memory that tends to get overwritten often, but
I've seen this in member variables. Like, uh, a couple of weeks ago ;-)

I'm not sure how this applies. I agree having the block zeroed would be a good idea for security, but that isn't what's happening.


- I can display the uninitialized sum in gdb, and it _isn't_ zero; I can even print the nonzero value via printf(). No VM-protected zero value. No initialize-on-read.

- If the garbage gets through printf(), with and without gdb, it's not a gdb artifact.

- If the strangeness disappears in a Release-configuration build, it's not an OS artifact.

- On PPC, stepping in assembly, the uninitialized sum loads into register $f0 as nonzero garbage. It is visible as such. It's only when y*y is added to $f0 that $f0 becomes y*y, as though $f0 had been zero all along.

- If the sum enters the chip from memory as nonzero, and is lost _while on the chip_, that's not a matter of block initialization, is it?

===========

Jack Repenning asks whether this is a matter of optimization. As shown in the assembly in my original post, there is no optimization going on. It's -O0 in the problem case. It's in the Release configuration, with optimization _on_, that the expected behavior appears.

Also, he speaks of having to use the stack a bit before garbage accumulates in a subsequent function's auto variables. Again: I had garbage. I read garbage in. I could print garbage.

===========

My immediate problem is not solved.

Now, maybe the best I can do is to find another "easy" bug for my students to learn from. But I am _intensely_ curious as to how this happened.

	— 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


  • Follow-Ups:
    • Re: C local auto-initialized? (persists)
      • From: Scott Ribe <email@hidden>
References: 
 >Re: C local auto-initialized? (From: Scott Ribe <email@hidden>)

  • Prev by Date: Re: C local auto-initialized?
  • Next by Date: Re: C local auto-initialized? (persists)
  • Previous by thread: Re: C local auto-initialized?
  • Next by thread: Re: C local auto-initialized? (persists)
  • Index(es):
    • Date
    • Thread