Re: Macnetworkprog Digest, Vol 2, Issue 229
Re: Macnetworkprog Digest, Vol 2, Issue 229
- Subject: Re: Macnetworkprog Digest, Vol 2, Issue 229
- From: "Smith Guo" <email@hidden>
- Date: Fri, 18 Nov 2005 15:04:31 +0800
where the const variable kCFStreamPropertyHTTPAttemptPersistentConnection defined ? Thank in advance!
Smith
----- Original Message -----
From: <email@hidden>
To: <email@hidden>
Sent: Friday, November 18, 2005 4:04 AM
Subject: Macnetworkprog Digest, Vol 2, Issue 229
> Send Macnetworkprog mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.apple.com/mailman/listinfo/macnetworkprog
> or, via email, send a message with subject or body 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Macnetworkprog digest..."
>
>
> Today's Topics:
>
> 1. Re: Kernel extension debugging tool? (Sam Vaughan)
> 2. Re: Kernel extension debugging tool? (Rob Barris)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 17 Nov 2005 09:20:56 +1100
> From: Sam Vaughan <email@hidden>
> Subject: Re: Kernel extension debugging tool?
> To: email@hidden
> Cc: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> On 17/11/2005, at 7:04 AM, Rob Barris <email@hidden> wrote:
>
> > The "paranoid malloc" we use in game debugging does all that
> > stuff and adds one more wrinkle: freed memory blocks are immediately
> > scrubbed with a fill pattern but those blocks are put on a free list
> > and not allowed to be recycled for any other allocation til they cool
> > off a bit (seconds to minutes, depending how much bloat you can
> > tolerate and how much RAM you have).
> > We have a watchdog that runs around all the freed blocks
> > periodically to make sure they are still scrubbed - if one isn't
> > scrubbed any more, it barks about it and dumps out the "who
> > allocated" and "who freed" call stacks, as well as showing which
> > offsets went sour. Conversely any faulty code that reads from freed
> > blocks usually fails spectacularly enough that it's easy to spot
> > (regs full of F1F1F1F1 etc). We call that "lazy free". The same
> > watchdog also scans the live block list to make sure no block-end has
> > been overrun etc.
> >
> > Hashing call stacks / stack-crawls is very useful - we use 8 or
> > 16 deep crawls. So the meta data we have to keep for each live block
> > is just a uint for the allocator-path and the freer-path, an index
> > into the stack-crawl hash table. That said we only invoke this tool
> > on machines with 2GB or more RAM handy.
>
> Hi Rob,
>
> You mentioned that this is for debugging games. Does that mean you
> get to do all this in user space? Half your luck ;o)
>
> Sam
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 16 Nov 2005 18:52:38 -0800
> From: Rob Barris <email@hidden>
> Subject: Re: Kernel extension debugging tool?
> To: Sam Vaughan <email@hidden>
> Cc: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On Nov 16, 2005, at 2:20 PM, Sam Vaughan wrote:
>
> > On 17/11/2005, at 7:04 AM, Rob Barris <email@hidden> wrote:
> >
> >
> >> The "paranoid malloc" we use in game debugging does all that
> >> stuff and adds one more wrinkle: freed memory blocks are immediately
> >> scrubbed with a fill pattern but those blocks are put on a free list
> >> and not allowed to be recycled for any other allocation til they cool
> >> off a bit (seconds to minutes, depending how much bloat you can
> >> tolerate and how much RAM you have).
> >> We have a watchdog that runs around all the freed blocks
> >> periodically to make sure they are still scrubbed - if one isn't
> >> scrubbed any more, it barks about it and dumps out the "who
> >> allocated" and "who freed" call stacks, as well as showing which
> >> offsets went sour. Conversely any faulty code that reads from freed
> >> blocks usually fails spectacularly enough that it's easy to spot
> >> (regs full of F1F1F1F1 etc). We call that "lazy free". The same
> >> watchdog also scans the live block list to make sure no block-end has
> >> been overrun etc.
> >>
> >> Hashing call stacks / stack-crawls is very useful - we use 8 or
> >> 16 deep crawls. So the meta data we have to keep for each live block
> >> is just a uint for the allocator-path and the freer-path, an index
> >> into the stack-crawl hash table. That said we only invoke this tool
> >> on machines with 2GB or more RAM handy.
> >>
> >
> > Hi Rob,
> >
> > You mentioned that this is for debugging games. Does that mean you
> > get to do all this in user space? Half your luck ;o)
>
> Well, yeah. And we only really intercept and track mallocs() &
> frees() that are called directly from our code, if something in
> Carbon or GL or BSD is doing double frees or write-after-free, we
> won't know about it.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.apple.com/mailman/private/macnetworkprog/attachments/20051116/1c83a52b/attachment.html
>
> ------------------------------
>
> _______________________________________________
> Macnetworkprog mailing list
> email@hidden
> http://lists.apple.com/mailman/listinfo/macnetworkprog
>
> End of Macnetworkprog Digest, Vol 2, Issue 229
> **********************************************
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden