Grès;3.z,...2,..;//9º,,=.==.\\\\]{

Inviato da iPhone

Il giorno 16/mar/2011, alle ore 18:24, cocoa-dev-requ...@lists.apple.comh]a 
scritto:

> Send Cocoa-dev mailing list submissions to
>    cocoa-dev@lists.apple.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://lists.apple.com/mailman/listinfo/cocoa-dev
> or, via email, send a message with subject or body 'help' to
>    cocoa-dev-requ...@lists.apple.com
> 
> You can reach the person managing the list at
>    cocoa-dev-ow...@lists.apple.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cocoa-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: NSTableView Column Count (Nicholas Zaccardi)
>   2. Re: NSTableView Column Count (Kyle Sluder)
>   3. Re: Debugging a sleepless Mac (Aaron Burghardt)
>   4. Re: Debugging a sleepless Mac (Kyle Sluder)
>   5. Re: NSTableView Column Count (Nicholas Zaccardi)
>   6. Re: NSTableView Column Count (Kyle Sluder)
>   7. Re: Books covering iOS security issues (Sean McBride)
>   8. RE: [Moderator] Lion NDA reminder (Shawn Bakhtiar)
>   9. RE: Books covering iOS security issues (Shawn Bakhtiar)
>  10. Re: Debugging a sleepless Mac (Matt Gough)
>  11. Re: crash in initWithCoder (James Maxwell)
>  12. Master Detail (Georg Seifert)
>  13. Re: crash in initWithCoder (James Maxwell)
>  14. Re: Debugging a sleepless Mac (Kyle Sluder)
>  15. Re: Books covering iOS security issues (Stephane Sudre)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 16 Mar 2011 11:09:51 -0400
> From: Nicholas Zaccardi <nicholas.zacca...@gmail.com>
> Subject: Re: NSTableView Column Count
> To: Indragie Karunaratne <cocoa...@indragie.com>
> Cc: cocoa-dev@lists.apple.com
> Message-ID:
>    <AANLkTim6tS9Zmbs=QHJ89atDAjn=yjecuu4aabwm-...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> That did not work for me, I resized it manually and it works, but I
> want to have IB do it automatically.
> 
> Thanks for any more suggestions.
> 
> On Wed, Mar 16, 2011 at 10:13 AM, Indragie Karunaratne
> <cocoa...@indragie.com> wrote:
>> This is a weird solution that worked for me:
>> 
>> 1. Decrease column count to one
>> 2. Click the "Headers" checkbox to disable table headers
>> 3. Click the "Headers" checkbox again to re-enable table headers, and it 
>> automatically sizes your single column to fill the entire width of the table
>> 
>> This seems to be more of a bug with Xcode but its a quick solution :)
>> 
>> On 2011-03-15, at 11:13 AM, Nicholas Zaccardi wrote:
>> 
>>> I am trying to make an NSTableView with only one column. Here is what I do:
>>> 
>>> 1. Open nib
>>> 2. Add TableView
>>> 3. Decrease column count
>>> 4. Save the NIB
>>> 
>>> However if I build and run, I still get 2 columns. Any suggestions?
>>> _______________________________________________
>>> 
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>> 
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>> 
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40indragie.com
>>> 
>>> This email sent to cocoa...@indragie.com
>> 
>> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 16 Mar 2011 08:16:24 -0700
> From: Kyle Sluder <kyle.slu...@gmail.com>
> Subject: Re: NSTableView Column Count
> To: Nicholas Zaccardi <nicholas.zacca...@gmail.com>
> Cc: cocoa-dev@lists.apple.com
> Message-ID:
>    <aanlktim7sv3efgfpdbmdsfdrvrkjs4t5mdatwjgtx...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Wed, Mar 16, 2011 at 8:09 AM, Nicholas Zaccardi
> <nicholas.zacca...@gmail.com> wrote:
>> That did not work for me, I resized it manually and it works, but I
>> want to have IB do it automatically.
> 
> Have IB do what automatically? NSTableView doesn't autoresize its
> columns unless they fit the exact visible width of the enclosing
> scrollview. If you remove the last column, the tableview no longer
> fills the scroll view, and therefore will not autosize its columns as
> you resize it in Interface Builder.
> 
> --Kyle Sluder
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 16 Mar 2011 11:22:05 -0400
> From: Aaron Burghardt <aaron.burgha...@gmail.com>
> Subject: Re: Debugging a sleepless Mac
> To: Matt Gough <mgo...@humyo.com>
> Cc: Cocoa <cocoa-dev@lists.apple.com>
> Message-ID: <fc853c3c-8bbd-4946-91d3-1718f06aa...@gmail.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> On Mar 16, 2011, at 8:37 AM, Matt Gough wrote:
> 
>> So it seems that something else is preventing idle sleep, but I've no idea 
>> how to find the culprit. Is there some defaults setting I can use that will 
>> log what the OS wants to do at sleep time and what is blocking it?
> 
> Leaving a Terminal session/window open seems to prevent sleep for me.
> 
> Aaron
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 16 Mar 2011 08:32:44 -0700
> From: Kyle Sluder <kyle.slu...@gmail.com>
> Subject: Re: Debugging a sleepless Mac
> To: Matt Gough <mgo...@humyo.com>
> Cc: Cocoa <cocoa-dev@lists.apple.com>
> Message-ID:
>    <AANLkTi=0edev9upiapn3nutyrdy3j9jbcphpczyrd...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Wed, Mar 16, 2011 at 5:37 AM, Matt Gough <mgo...@humyo.com> wrote:
>> So it seems that something else is preventing idle sleep, but I've no idea 
>> how to find the culprit. Is there some defaults setting I can use that will 
>> log what the OS wants to do at sleep time and what is blocking it?
> 
> According to the I/O Kit Power Management Release Notes, `pmset -g`
> should list all outstanding power management assertions.
> http://developer.apple.com/library/mac/#releasenotes/Darwin/RN-IOKitPowerManagment/_index.html
> 
> I'd say try that and see if it tells you who's preventing system sleep.
> 
> --Kyle Sluder
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 16 Mar 2011 11:44:45 -0400
> From: Nicholas Zaccardi <nicholas.zacca...@gmail.com>
> Subject: Re: NSTableView Column Count
> To: Kyle Sluder <kyle.slu...@gmail.com>
> Cc: cocoa-dev@lists.apple.com
> Message-ID:
>    <aanlktinxqwkwvxsxke5agwqhf86ofpmnojxfmzdl5...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Okay.  This is not a problem per say, but let me make sure I understand you.
> 
> In order for a single column to fill the entire width of a scroll
> view, I have to make the width of the column the width of the scroll
> view - the scroll bars?
> 
> For example, a scroll view is 100 wide and my NSTableView is also 100
> wide, but the one and only column is only 65 wide then I would have to
> manually make it 100 in order for the column to make use of the full
> NSTableView.  XCode/IB/Cocoa will not do that for me.
> 
> Then if I resize the window/Scroll/TableView will the column auto resize?
> 
> Thank you for helping me understand this!
> 
> 
> On Wed, Mar 16, 2011 at 11:16 AM, Kyle Sluder <kyle.slu...@gmail.com> wrote:
>> On Wed, Mar 16, 2011 at 8:09 AM, Nicholas Zaccardi
>> <nicholas.zacca...@gmail.com> wrote:
>>> That did not work for me, I resized it manually and it works, but I
>>> want to have IB do it automatically.
>> 
>> Have IB do what automatically? NSTableView doesn't autoresize its
>> columns unless they fit the exact visible width of the enclosing
>> scrollview. If you remove the last column, the tableview no longer
>> fills the scroll view, and therefore will not autosize its columns as
>> you resize it in Interface Builder.
>> 
>> --Kyle Sluder
>> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 16 Mar 2011 08:51:32 -0700
> From: Kyle Sluder <kyle.slu...@gmail.com>
> Subject: Re: NSTableView Column Count
> To: Nicholas Zaccardi <nicholas.zacca...@gmail.com>
> Cc: cocoa-dev@lists.apple.com
> Message-ID:
>    <AANLkTi=mGm24rpqfQMKEF=X1f=oqzesrwdczs7oj6...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Wed, Mar 16, 2011 at 8:44 AM, Nicholas Zaccardi
> <nicholas.zacca...@gmail.com> wrote:
>> In order for a single column to fill the entire width of a scroll
>> view, I have to make the width of the column the width of the scroll
>> view - the scroll bars?
>> 
>> For example, a scroll view is 100 wide and my NSTableView is also 100
>> wide, but the one and only column is only 65 wide then I would have to
>> manually make it 100 in order for the column to make use of the full
>> NSTableView.  XCode/IB/Cocoa will not do that for me.
>> 
>> Then if I resize the window/Scroll/TableView will the column auto resize?
> 
> Yes. As Indragie mentioned, you might need to temporarily turn on
> column headers so you have something to resize.
> 
> --Kyle Sluder
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed, 16 Mar 2011 12:10:06 -0400
> From: Sean McBride <s...@rogue-research.com>
> Subject: Re: Books covering iOS security issues
> To: Eric Gorr <mail...@ericgorr.net>,    Cocoa Dev
>    <cocoa-dev@lists.apple.com>
> Message-ID: <20110316161006.906873...@mail.rogue-research.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Wed, 16 Mar 2011 10:20:49 -0400, Eric Gorr said:
> 
>> I was just wondering if there were any books people would recommend,
>> apart from Apple's documentation on the topic ( http://bit.ly/gz36Bn,
>> etc. ), which discuss security issues and best-coding practices for iOS.
> 
> Since you're likely working in a C-based language, this could be educational:
> 
> <https://www.securecoding.cert.org/confluence/display/seccode/CERT+C
> +Secure+Coding+Standard>
> 
> -- 
> ____________________________________________________________
> Sean McBride, B. Eng                 s...@rogue-research.com
> Rogue Research                        www.rogue-research.com 
> Mac Software Developer              Montréal, Québec, Canada
> 
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Wed, 16 Mar 2011 12:22:03 -0400
> From: Shawn Bakhtiar <shashan...@hotmail.com>
> Subject: RE: [Moderator] Lion NDA reminder
> To: sc...@cocoadoc.com, cocoa-dev@lists.apple.com
> Message-ID: <snt125-w45862e7c19d448a728fffc4...@phx.gbl>
> Content-Type: text/plain; charset="Windows-1252"
> 
> 
> 
> In the jungle the quiet jungle...
> The lion sleeps tonight...
> 
> In the jungle the quite jungle....
> The lion sleeps tonight....
> 
> Owimboeh... owimboeh...
> Owimboeh... owimboeh...
> 
> Owimboeh... owimboeh...
> Owimboeh... owimboeh...
> 
>> From: sc...@cocoadoc.com
>> Date: Wed, 16 Mar 2011 01:13:27 -0400
>> To: cocoa-dev@lists.apple.com
>> Subject: [Moderator] Lion NDA reminder
>> 
>> While there haven’t been any issues that I’m aware of I wanted to take an 
>> opportunity to remind subscribers...
>> 
>> Lion APIs, features, changes, etc. are all covered by non-disclosure. So 
>> they can’t be discussed here.
>> 
>> However, there are forums at devforums.apple.com that have facilities for 
>> this.
>> 
>> So head over there for those questions/comments/etc.
>> 
>> Thanks in advance
>> 
>> [scott]
>> moderator
>> 
>> _______________________________________________
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/shashaness%40hotmail.com
>> 
>> This email sent to shashan...@hotmail.com
>                         
> 
> ------------------------------
> 
> Message: 9
> Date: Wed, 16 Mar 2011 12:26:42 -0400
> From: Shawn Bakhtiar <shashan...@hotmail.com>
> Subject: RE: Books covering iOS security issues
> To: s...@rogue-research.com, mail...@ericgorr.net,
>    cocoa-dev@lists.apple.com
> Message-ID: <snt125-w5549e337e74191f8577836c4...@phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> 
> http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007072
> 
> I've looked. This is the best. The examples are all there, and it does a 
> pretty good job of explaining how to do things. 
> 
>> From: s...@rogue-research.com
>> To: mail...@ericgorr.net; cocoa-dev@lists.apple.com
>> Date: Wed, 16 Mar 2011 12:10:06 -0400
>> CC: 
>> Subject: Re: Books covering iOS security issues
>> 
>> On Wed, 16 Mar 2011 10:20:49 -0400, Eric Gorr said:
>> 
>>> I was just wondering if there were any books people would recommend,
>>> apart from Apple's documentation on the topic ( http://bit.ly/gz36Bn,
>>> etc. ), which discuss security issues and best-coding practices for iOS.
>> 
>> Since you're likely working in a C-based language, this could be educational:
>> 
>> <https://www.securecoding.cert.org/confluence/display/seccode/CERT+C
>> +Secure+Coding+Standard>
>> 
>> -- 
>> ____________________________________________________________
>> Sean McBride, B. Eng                 s...@rogue-research.com
>> Rogue Research                        www.rogue-research.com 
>> Mac Software Developer              Montréal, Québec, Canada
>> 
>> 
>> _______________________________________________
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/shashaness%40hotmail.com
>> 
>> This email sent to shashan...@hotmail.com
>                         
> 
> ------------------------------
> 
> Message: 10
> Date: Wed, 16 Mar 2011 16:35:41 +0000
> From: Matt Gough <mgo...@humyo.com>
> Subject: Re: Debugging a sleepless Mac
> To: Kyle Sluder <kyle.slu...@gmail.com>
> Cc: Cocoa <cocoa-dev@lists.apple.com>
> Message-ID: <d65e6b13-a0ff-41ac-a77d-6e2b1f390...@humyo.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> On 16 Mar 2011, at 15:32, Kyle Sluder wrote:
> 
>> On Wed, Mar 16, 2011 at 5:37 AM, Matt Gough <mgo...@humyo.com> wrote:
>>> So it seems that something else is preventing idle sleep, but I've no idea 
>>> how to find the culprit. Is there some defaults setting I can use that will 
>>> log what the OS wants to do at sleep time and what is blocking it?
>> 
>> According to the I/O Kit Power Management Release Notes, `pmset -g`
>> should list all outstanding power management assertions.
>> http://developer.apple.com/library/mac/#releasenotes/Darwin/RN-IOKitPowerManagment/_index.html
>> 
>> I'd say try that and see if it tells you who's preventing system sleep.
>> 
>> --Kyle Sluder
> 
> 
> Thanks to everyone for the suggestions so far.
> 
> Alas, pmset -g it doesn't show any active assertions (I know it can do as I 
> slapped one in my code and it showed up).
> 
> I have also tried turning off ttyskeepawake, but to no avail.
> 
> I didn't mention in my previous email that I have no problem with display 
> sleep working correctly, its just idle sleep that is misbehaving.
> 
> Looking through the logs, I can't see any power related ones.
> 
> Apart from user interactions, what other sorts of activity automatically 
> prevent idle sleep?
> 
> Matt
> 
> ------------------------------
> 
> Message: 11
> Date: Wed, 16 Mar 2011 09:56:37 -0700
> From: James Maxwell <jbmaxw...@rubato-music.com>
> Subject: Re: crash in initWithCoder
> To: Cocoa Dev <cocoa-dev@lists.apple.com>
> Message-ID: <8180fa67-df0d-4891-a56b-255f16ea3...@rubato-music.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Thanks Greg. The initWithCoder is indeed at launch, so Guard Malloc shouldn't 
> be a huge problem. I'll give it a try.
> 
> cheers,
> 
> J.
> 
> On 2011-03-15, at 6:45 PM, Greg Parker wrote:
> 
>> On Mar 15, 2011, at 4:10 PM, James Maxwell wrote:
>>> I'm getting a crash in initWithCoder, which seems related to decoding a 
>>> property called "value", which is of type id. Sometimes this object is an 
>>> NSString, sometimes it's an NSNumber, and sometimes it's an NSArray. The 
>>> crash only occurs in cases where "value" is an NSArray. The last few lines 
>>> in my backtrace are:
>>> 
>>> #0  0x963c4206 in szone_malloc_should_clear ()
>>> #1  0x963c41a8 in malloc_zone_malloc ()
>>> #2  0x94920a13 in _CFRuntimeCreateInstance ()
>>> #3  0x94943482 in CFNumberCreate ()
>>> #4  0x949586f2 in __CFBinaryPlistCreateObject2 ()
>>> #5  0x94985fe0 in __CFBinaryPlistCreateObject ()
>>> #6  0x9823eb11 in _decodeObjectBinary ()
>>> #7  0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] ()
>>> #8  0x98240981 in -[NSArray(NSArray) initWithCoder:] ()
>>> #9  0x9823f508 in _decodeObjectBinary ()
>>> #10 0x9823e800 in _decodeObject ()
>>> #11 0x000cdf05 in -[CbCM_Node initWithCoder:] (self=0x4098770, 
>>> _cmd=0x9433805c, aDecoder=0x410f1c0) at 
>>> /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore
>>>  Test Build/ManuScore/CbCM_Node.m:573
>>> 
>>> From this, I'm guessing that the problem is happening with one of the 
>>> members of the "value" array. Does that seem right? (I should mention, 
>>> though, that the trace isn't always the same...)
>>> I am retaining "value" when I decode it, so it's not a simple memory bug. I 
>>> have also run the code with Zombies (NSZombieEnabled=YES), which doesn't 
>>> indicate any Zombied objects. Finally, the analyzer sees no memory errors 
>>> (there are a number of "dead stores" - mostly unused variables - but these 
>>> aren't likely to be real problems, are they?), so I'm stumped. I'm running 
>>> Xcode 4, btw.
>> 
>> A crash inside malloc generally means that there's a memory error elsewhere 
>> that corrupted malloc's data structures. (Actual bugs in malloc are rare.) 
>> malloc may store information before or after each allocation, and inside 
>> freed allocations.
>> 
>> The usual bugs are:
>> * writing data before or after the bounds of an allocation. Usually this 
>> comes from bounds errors in C arrays.
>> * writing data into an allocation after freeing it. 
>> 
>> NSZombie catches the latter for Objective-C objects. But if the problem is a 
>> non-object allocation, or a bounds error, then NSZombie won't help. 
>> 
>> The next tool to try is Guard Malloc. It catches both of the above errors 
>> for any malloc allocation. On the down side, it is slow and memory 
>> intensive, but if this -initWithCoder: is running early in app launch then 
>> you won't have any trouble with it.
>> 
>> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/guardmalloc.3.html
>> 
>> 
>> -- 
>> Greg Parker     gpar...@apple.com     Runtime Wrangler
>> 
>> 
> 
> James B Maxwell
> Composer/Doctoral Student
> School for the Contemporary Arts (SCA)
> School for Interactive Arts + Technology (SIAT)
> Simon Fraser University
> jbmaxw...@rubato-music.com
> jbmax...@sfu.ca
> 
> 
> 
> ------------------------------
> 
> Message: 12
> Date: Wed, 16 Mar 2011 17:57:20 +0100
> From: Georg Seifert <georg.seif...@gmx.de>
> Subject: Master Detail
> To: Cocoa Developers <cocoa-dev@lists.apple.com>
> Message-ID: <023dc9ef-3569-41b2-b6bb-e096886cf...@gmx.de>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi,
> 
> If I have a master detail interface bound to a array controller.
> 
> To explain my problem (the actual structure is different but as an 
> explanation):
> The list shows a some persons. Then I have a switch that selects if the 
> detail view shows the private or the work address. Is there any easy way do 
> that. 
> 
> Now I use another array controller. On every selection change I make an array 
> of addresses and set as the content array.
> 
> Is there an easier solution?
> 
> Or can I change the keypath if the address switch changes?
> 
> Best
> Georg
> 
> ------------------------------
> 
> Message: 13
> Date: Wed, 16 Mar 2011 10:00:29 -0700
> From: James Maxwell <jbmaxw...@rubato-music.com>
> Subject: Re: crash in initWithCoder
> To: Cocoa Dev <cocoa-dev@lists.apple.com>
> Message-ID: <2445c2d3-f824-4e4a-a8e2-5d8f880e8...@rubato-music.com>
> Content-Type: text/plain; charset=us-ascii
> 
> oops... How do I enable Guard Malloc in Xcode 4?
> 
> J.
> 
> 
> On 2011-03-15, at 6:45 PM, Greg Parker wrote:
> 
>> On Mar 15, 2011, at 4:10 PM, James Maxwell wrote:
>>> I'm getting a crash in initWithCoder, which seems related to decoding a 
>>> property called "value", which is of type id. Sometimes this object is an 
>>> NSString, sometimes it's an NSNumber, and sometimes it's an NSArray. The 
>>> crash only occurs in cases where "value" is an NSArray. The last few lines 
>>> in my backtrace are:
>>> 
>>> #0  0x963c4206 in szone_malloc_should_clear ()
>>> #1  0x963c41a8 in malloc_zone_malloc ()
>>> #2  0x94920a13 in _CFRuntimeCreateInstance ()
>>> #3  0x94943482 in CFNumberCreate ()
>>> #4  0x949586f2 in __CFBinaryPlistCreateObject2 ()
>>> #5  0x94985fe0 in __CFBinaryPlistCreateObject ()
>>> #6  0x9823eb11 in _decodeObjectBinary ()
>>> #7  0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] ()
>>> #8  0x98240981 in -[NSArray(NSArray) initWithCoder:] ()
>>> #9  0x9823f508 in _decodeObjectBinary ()
>>> #10 0x9823e800 in _decodeObject ()
>>> #11 0x000cdf05 in -[CbCM_Node initWithCoder:] (self=0x4098770, 
>>> _cmd=0x9433805c, aDecoder=0x410f1c0) at 
>>> /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore
>>>  Test Build/ManuScore/CbCM_Node.m:573
>>> 
>>> From this, I'm guessing that the problem is happening with one of the 
>>> members of the "value" array. Does that seem right? (I should mention, 
>>> though, that the trace isn't always the same...)
>>> I am retaining "value" when I decode it, so it's not a simple memory bug. I 
>>> have also run the code with Zombies (NSZombieEnabled=YES), which doesn't 
>>> indicate any Zombied objects. Finally, the analyzer sees no memory errors 
>>> (there are a number of "dead stores" - mostly unused variables - but these 
>>> aren't likely to be real problems, are they?), so I'm stumped. I'm running 
>>> Xcode 4, btw.
>> 
>> A crash inside malloc generally means that there's a memory error elsewhere 
>> that corrupted malloc's data structures. (Actual bugs in malloc are rare.) 
>> malloc may store information before or after each allocation, and inside 
>> freed allocations.
>> 
>> The usual bugs are:
>> * writing data before or after the bounds of an allocation. Usually this 
>> comes from bounds errors in C arrays.
>> * writing data into an allocation after freeing it. 
>> 
>> NSZombie catches the latter for Objective-C objects. But if the problem is a 
>> non-object allocation, or a bounds error, then NSZombie won't help. 
>> 
>> The next tool to try is Guard Malloc. It catches both of the above errors 
>> for any malloc allocation. On the down side, it is slow and memory 
>> intensive, but if this -initWithCoder: is running early in app launch then 
>> you won't have any trouble with it.
>> 
>> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/guardmalloc.3.html
>> 
>> 
>> -- 
>> Greg Parker     gpar...@apple.com     Runtime Wrangler
>> 
>> 
> 
> James B Maxwell
> Composer/Doctoral Student
> School for the Contemporary Arts (SCA)
> School for Interactive Arts + Technology (SIAT)
> Simon Fraser University
> jbmaxw...@rubato-music.com
> jbmax...@sfu.ca
> 
> 
> 
> ------------------------------
> 
> Message: 14
> Date: Wed, 16 Mar 2011 09:59:29 -0700
> From: Kyle Sluder <kyle.slu...@gmail.com>
> Subject: Re: Debugging a sleepless Mac
> To: Matt Gough <mgo...@humyo.com>
> Cc: Cocoa <cocoa-dev@lists.apple.com>
> Message-ID: <32e78ae2-b6c3-4500-b7e2-d8d8eb978...@gmail.com>
> Content-Type: text/plain; charset=us-ascii
> 
> On Mar 16, 2011, at 9:35 AM, Matt Gough <mgo...@humyo.com> wrote:
> 
>> Apart from user interactions, what other sorts of activity automatically 
>> prevent idle sleep?
> 
> Time Machine, I think?
> 
> --Kyle Sluder
> 
> ------------------------------
> 
> Message: 15
> Date: Wed, 16 Mar 2011 18:22:19 +0100
> From: Stephane Sudre <dev.iceb...@gmail.com>
> Subject: Re: Books covering iOS security issues
> To: Eric Gorr <mail...@ericgorr.net>
> Cc: Cocoa Dev <cocoa-dev@lists.apple.com>
> Message-ID:
>    <AANLkTi=eqv8agzn-5iodj4jffa4hxabf2bfg4hhff...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> I haven't read it so it's just to add a reference to the list:
> 
> Professional Cocoa Application Security
> Graham J. Lee, Wrox, 2010
> ISBN 978-0-470-52595-1, £33.99
> http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470525959.html
> 
> 
> ------------------------------
> 
> _______________________________________________
> 
> Cocoa-dev mailing list      (Cocoa-dev@lists.apple.com)
> 
> Do not post admin requests or moderator comments to the list.  
> Contact the moderators at cocoa-dev-admins (at) lists.apple.com
> 
> http://lists.apple.com/mailman/listinfo/cocoa-dev
> 
> 
> End of Cocoa-dev Digest, Vol 8, Issue 190
> *****************************************
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to