Hmm.
Some more testing has enabled me to remove my Cocoa wrapper altogether and the
issue persists.
So I will move the query over to the Xcode list.
> On 2 Nov 2015, at 09:45, Jonathan Mitchell wrote:
>
> This has me puzzled.
>
> I have some code that is giving trouble only when built on 10.11
From this backtrace it looks like you might be trying to perform UI operations
someplace other than on the main queue, which would cause problems. I'd start
by checking whether you have:
-Any dispatches to a background queue that might need a dispatch_async to the
main queue.
-Any observer call
Thanks Mike.. I will try that and check for memory leaks in my app
On Mon, Jun 22, 2015 at 2:38 PM, Mike Abdullah
wrote:
> Have you experimented with passing something bigger than CGRectZero for
> the web view’s initial size? Maybe it’s freaking out over that.
>
> Some googling also suggests tha
Have you experimented with passing something bigger than CGRectZero for the web
view’s initial size? Maybe it’s freaking out over that.
Some googling also suggests that the bbadbeef code can mean WebKit couldn’t
allocate enough memory. Maybe you’re using too much memory in your app in total?
>
On May 28, 2014, at 10:24 PM, Uli Kusterer wrote:
> That said, if you want to be really endian-safe, use an XML file format saved
> as UTF-8 like Property Lists. Most portable format there is. :-)
Thanks a lot. I have to go rinse out my mouth now.
--
Scott Ribe
scott_r...@elevated-dev.com
htt
On May 28, 2014, at 11:24 PM, Uli Kusterer wrote:
> Or change struct alignment or the size of ints or … I’ve been programming for
> a couple of days, I’ve taken this into account. But I’d rather retroactively
> go and fix something (you have to re-test when porting to a new platform
> anyway)
On May 27, 2014, at 3:51 PM, Greg Parker wrote:
> On May 27, 2014, at 12:52 PM, Charles Srstka wrote:
>> On May 27, 2014, at 2:08 PM, Greg Parker wrote:
>>> On May 26, 2014, at 8:28 PM, Charles Srstka
>>> wrote:
On May 26, 2014, at 7:43 PM, Uli Kusterer
wrote:
> Regarding endi
On 26 May 2014, at 20:28, Charles Srstka wrote:
> On May 26, 2014, at 7:43 PM, Uli Kusterer
> wrote:
>> Regarding endian-swapping, that depends on the file format. If you wrote
>> that file yourself, you don’t usually need to do any swapping.
>
> That's true. For example, back in the PowerPC d
On 28 May 2014, at 5:52 am, Charles Srstka wrote:
> a) 'bar' is a later addition to the file format, added some time after the
> app was ported to Intel, and thus is in little-endian format whereas the
> older parts of the file are in big-endian (and yes, I've seen formats that do
> this), or
On May 27, 2014, at 12:08 PM, Greg Parker wrote:
> Untested code is incorrect code. Don't write endian-swapping code that you
> can't test because you aren't using any other-endian platforms today.
I disagree. There is a strong, longstanding convention for cross-platform
binary data formats
On May 27, 2014, at 12:52 PM, Charles Srstka wrote:
> On May 27, 2014, at 2:08 PM, Greg Parker wrote:
>> On May 26, 2014, at 8:28 PM, Charles Srstka wrote:
>>> On May 26, 2014, at 7:43 PM, Uli Kusterer
>>> wrote:
Regarding endian-swapping, that depends on the file format. If you wrote
>>
On May 27, 2014, at 2:08 PM, Greg Parker wrote:
> On May 26, 2014, at 8:28 PM, Charles Srstka wrote:
>> On May 26, 2014, at 7:43 PM, Uli Kusterer
>> wrote:
>>> Regarding endian-swapping, that depends on the file format. If you wrote
>>> that file yourself, you don’t usually need to do any swa
On May 26, 2014, at 8:28 PM, Charles Srstka wrote:
> On May 26, 2014, at 7:43 PM, Uli Kusterer
> wrote:
>> Regarding endian-swapping, that depends on the file format. If you wrote
>> that file yourself, you don’t usually need to do any swapping.
>
> That's true. For example, back in the PowerP
On May 26, 2014, at 7:43 PM, Uli Kusterer wrote:
> Regarding endian-swapping, that depends on the file format. If you wrote that
> file yourself, you don’t usually need to do any swapping.
That's true. For example, back in the PowerPC days, we never had to endian-swap
our file formats, because
On 27 May 2014, at 10:13 am, Jens Alfke wrote:
> No, it’s extremely common to have a data format where a variable-length field
> is prefixed with its length. That looks like what this code is trying to read.
Alright, but you have to know that. I was looking at the code from a general
standpoi
On 26 May 2014, at 16:20, Graham Cox wrote:
> On 27 May 2014, at 12:54 am, Roland King wrote:
>> datasize = *((unsigned int*)bytes);
>>
>> is a bit closer to what you might want but is endian-unaware.
>
> That's just as wrong - you are using the first few bytes of the data as the
> length, w
On May 26, 2014, at 4:20 PM, Graham Cox wrote:
> That's just as wrong - you are using the first few bytes of the data as the
> length, which it certainly isn't (except for possibly a very few special
> cases that just so happen to have the length as the first field of the data).
No, it’s extr
On 27 May 2014, at 12:54 am, Roland King wrote:
> datasize = *((unsigned int*)bytes);
>
> is a bit closer to what you might want but is endian-unaware.
That's just as wrong - you are using the first few bytes of the data as the
length, which it certainly isn't (except for possibly a very fe
On May 26, 2014, at 6:02 AM, Pax <45rpmli...@googlemail.com> wrote:
> When this gets run, I get EXC_BAD_ACCESS code = 2 here. I'm demonstrably
> reading less data than the file contains, and I've been able to read through
> the file successfully up to this point. Please could someone suggest
On May 26, 2014, at 10:06 AM, Pax <45rpmli...@googlemail.com> wrote:
> As I say though, I think that the solution I posted is the better solution
> anyway - since who wants a copy, with the additional overhead that a copy
> entails, when you don't need to have one?
Absolutely. (For read-only ac
Shameful. I need more sleep! :-) I also need to reread my code more carefully
before asking questions.
As I say though, I think that the solution I posted is the better solution
anyway - since who wants a copy, with the additional overhead that a copy
entails, when you don't need to have on
On May 26, 2014, at 9:32 AM, Uli Kusterer wrote:
> Oh, and as Roland wrote, don’t forget to free() the pointer once you’re done
> with it.
But, just to be 100% clear, *not* the one you get from calling the bytes method
;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com
Too true. That was a lot of bugs in 4 lines!
> On 26 May, 2014, at 11:18 pm, Scott Ribe wrote:
>
>> On May 26, 2014, at 9:05 AM, Roland King wrote:
>>
>> The first one of those is ok...
>
> No, it's not--take a closer look ;-)
>
>> unsigned char* databuffer = (unsigned char*)malloc(datasize)
On 26 May 2014, at 06:44, Pax <45rpmli...@googlemail.com> wrote:
> Apologies - the obvious important detail, and I missed it out entirely. I
> have tried both of the following with the same result:
>
> unsigned char* databuffer = (unsigned char*)malloc(datasize);
> [datastream getBytes:&data
On May 26, 2014, at 9:05 AM, Roland King wrote:
> The first one of those is ok...
No, it's not--take a closer look ;-)
> unsigned char* databuffer = (unsigned char*)malloc(datasize);
> [datastream getBytes:&databuffer range:NSMakeRange(positionCounter,
> datasize)];
--
Scott Ribe
scott_r...
The first one of those is ok - as long as you remember to free databuffer
later. The second is wrong, the argument to getBytes:range: has to be an
allocated buffer of size at least the length of the range you pass in. That
second one is just copying data to a random place in memory, probably zer
On May 26, 2014, at 8:43 AM, Pax <45rpmli...@googlemail.com> wrote:
> I should, I know, find out what was going wrong initially - but since I'd
> rather not have a copy anyway, this really is the all-round better solution.
What was wrong was that instead of passing the address of the buffer you
So you have
unsigned char *bytes;
and then
datasize = (unsigned int)bytes;
which sets datasize to the address of bytes cast to an unsigned integer which
has nothing to do with the data in bytes at all and in some cases just
truncates the address (OSX for instance)
datasize = *((unsigned in
Just to answer my own question, I find that:
bytes=[[datastream subdataWithRange:NSMakeRange(positionCounter,
datasize)]bytes];
Works perfectly.
I should, I know, find out what was going wrong initially - but since I'd
rather not have a copy anyway, this really is the all-round better solution
Well,
I find your code to be a bit confusing, but I’d say that both of those are
wrong. I think that what you need is:
unsigned char* databuffer = (unsigned char*)malloc(datasize);
[datastream getBytes:databuffer range:NSMakeRange(positionCounter,
datasize)]; // Packet content
On May 26,
Apologies - the obvious important detail, and I missed it out entirely. I have
tried both of the following with the same result:
unsigned char* databuffer = (unsigned char*)malloc(datasize);
[datastream getBytes:&databuffer range:NSMakeRange(positionCounter,
datasize)]; // Packet content
Apologies - the obvious important detail, and I missed it out entirely. I have
tried both of the following with the same result:
unsigned char* databuffer = (unsigned char*)malloc(datasize);
[datastream getBytes:&databuffer range:NSMakeRange(positionCounter,
datasize)]; // Packet content
On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote:
> This is my snippet of code:
>[datastream getBytes:&bytes
> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
>positionCounter+= datasize;
What is bytes declared as,
That certainly made a difference. It's choking on a nib
#0 0x97876d54 in objc_msgSend ()
#1 0x96e6a960 in CFHash ()
#2 0x96e709c0 in __CFSetStandardHashKey ()
#3 0x96e740c2 in CFBasicHashAddValue ()
#4 0x96e8b2d4 in CFSetAddValue ()
#5 0x96ee3395 in -[__NSCFSet addObject:] ()
#6 0x94a595b1 in -[NS
On Jul 24, 2011, at 15:50, Ayers, Joseph wrote:
> In XCode 4.1. and Lion,, compiling for OS X 10.6, My application is crashing
> in main.m. Specifically it exhibits EXC_BAD_ACCESS errors in main.m,
> NSApplicationMain and obj_msgSend on disassembly. I've got symbolic
> breakpoints at: “objc_ex
Hi Joseph,
If you type 'bt' in GDB, do you see something like this by any chance?:
> #74 0x7fff8686f312 in -[NSIBObjectData initWithCoder:] ()
> #75 0x7fff827fbe73 in _decodeObjectBinary ()
> #76 0x7fff827fb2ed in _decodeObject ()
> #77 0x7fff8686ea41 in loadNib ()
> #78 0x7ff
On Fri, Jan 28, 2011 at 12:19 PM, Michael LaMorte
wrote:
> Program received signal: “EXC_BAD_ACCESS”.
You have a memory management bug somewhere. I'm guessing that you've
failed to retain an NSManagedObject.
--Kyle Sluder
___
Cocoa-dev mailing list (
Il giorno 17/gen/2011, alle ore 04.04, Kyle Sluder ha scritto:
> On Sun, Jan 16, 2011 at 4:48 PM, Marco Frisan wrote:
>> Yes I know that. The problem is that I am was not able to find which
>> pointer. And the reason I am not able to find it is that the line that cause
>> the application block
On Jan 16, 2011, at 10:37 PM, Marco Frisan wrote:
> I verified with Instruments - Leaks the version available on the provided
> link (since I modified my local copy) and the result is that I have no memory
> leak.
A leak is when something is under-released. The most likely culprit in your
cas
Il giorno 17/gen/2011, alle ore 03.02, William Squires ha scritto:
> I'd have a look at your object allocations/deallocations with Instruments -
> this sort of cr*p usually means you over-released something, or you forgot to
> retain it. Remember that containers have no way of knowing if you
>
On Sun, Jan 16, 2011 at 4:48 PM, Marco Frisan wrote:
> Yes I know that. The problem is that I am was not able to find which pointer.
> And the reason I am not able to find it is that the line that cause the
> application block is:
>
> NSDictionary * attributes = _record.attributes;
>
> inside th
Il giorno 16/gen/2011, alle ore 19.06, Kyle Sluder ha scritto:
> On Jan 15, 2011, at 3:55 AM, Marco Frisan wrote:
>
>> I don't understand why _record.attributes causes a “EXC_BAD_ACCESS” signal.
>
> This is the defining characteristic of a memory management bug: you have a
> pointer to an obje
On Jan 15, 2011, at 3:55 AM, Marco Frisan wrote:
> I don't understand why _record.attributes causes a “EXC_BAD_ACCESS” signal.
This is the defining characteristic of a memory management bug: you have a
pointer to an object that has since been freed. Trying to use that pointer is
an error.
--K
I rolled back my xcode, seems to be an Xcode 3.2.3 issue.
On May 7, 2010, at 12:04 PM, Kyle Sluder wrote:
> On Fri, May 7, 2010 at 11:57 AM, Brent Smith wrote:
>> When i run an NSLog on newLinesString I get this,
>> 2010-05-07 11:56:07.604 testingApp[2573:a0f] ‡√Kpˇ
>>
>> When it should be som
On Fri, May 7, 2010 at 11:57 AM, Brent Smith wrote:
> When i run an NSLog on newLinesString I get this,
> 2010-05-07 11:56:07.604 testingApp[2573:a0f] ‡√Kpˇ
>
> When it should be some readable english form a text file.
> I am at a loss :(
Well, it's quite apparent you have a memory management bug
When i run an NSLog on newLinesString I get this,
2010-05-07 11:56:07.604 testingApp[2573:a0f] ‡√Kpˇ
When it should be some readable english form a text file.
I am at a loss :(
On May 6, 2010, at 8:08 PM, Kyle Sluder wrote:
> On Thu, May 6, 2010 at 7:21 PM, Brent Smith wrote:
>> I have an NS
Its got to be something im doing wrong. Not certain though.
On May 6, 2010, at 9:45 PM, Tino Rachui wrote:
> Interesting I see this behavior as well when I debug my (completely
> different) program. I ask on the ADC lists already. No answer so far. Maybe
> this is a gdb bug!?
> -Tino
>
> Sent
Interesting I see this behavior as well when I debug my (completely
different) program. I ask on the ADC lists already. No answer so far.
Maybe this is a gdb bug!?
-Tino
Sent by mobile
Am 07.05.2010 um 04:21 schrieb Brent Smith :
Hey all,
I have an NSTask thats running a method for me and
On May 6, 2010, at 8:08 PM, Kyle Sluder wrote:
> On Thu, May 6, 2010 at 7:21 PM, Brent Smith wrote:
>> I have an NSTask thats running a method for me and Im trying to debug why
>> its currently not working. I can go about using my program normally when I
>> select Build and Run, but when I add
Sorry about the retain, I was just trying that.
On May 6, 2010, at 8:08 PM, Kyle Sluder wrote:
> On Thu, May 6, 2010 at 7:21 PM, Brent Smith wrote:
>> I have an NSTask thats running a method for me and Im trying to debug why
>> its currently not working. I can go about using my program normall
On Thu, May 6, 2010 at 7:21 PM, Brent Smith wrote:
> I have an NSTask thats running a method for me and Im trying to debug why its
> currently not working. I can go about using my program normally when I select
> Build and Run, but when I add a breakpoint and select Build and Debug I get
> an E
isn't this almost exactly the same question you asked a week ago? It looks like
you did 1/2 of what Graham told you then but didn't totally understand his
answer.
Same answer, you're setting path to a newly-created NSBezierPath you don't own
and overwriting the one you alloc/init'ed earlier. S
Oops, sorry, my dealloc was buggy o.O
- (void)dealloc
{
[path release];
[super dealloc];
}
Bob
On 11 Mar 2010, at 13:38, Billy Flatman wrote:
> Hi All,
>
> I'm getting a 'EXC_BAD_ACCESS' error when calling the fill on a NSBezierPath.
> Below is an outline of my code.
>
>
> @interface Sha
Your initBezierPath method reallocates and reinitialises a path that's already
been created. It also autoreleases the result (as the allocation method
doesn't start with alloc, copy, mutableCopy, retain or new).
The result is that the first time 'path' is assigned it gets a non-released
value.
On Feb 18, 2010, at 9:17 AM, Gustavo Pizano wrote:
> HEllo Corbin,
> It seem its fixed, I didn't realize an ivar in the Custom NSCell, I forgot I
> put it there thinking in using it to hold the name of the user and be able to
> sort the table, which right now I can;t tell how to do it, I took
HEllo Corbin,
It seem its fixed, I didn't realize an ivar in the Custom NSCell, I forgot I
put it there thinking in using it to hold the name of the user and be able to
sort the table, which right now I can;t tell how to do it, I took out that
ivar, and it hasn't crash so far.. still Im gonna k
On Feb 18, 2010, at 12:24 AM, Gustavo Pizano wrote:
> Hello Corbin.
>
> ok, so I read your blog post, its great, I love it.
>
> I followed what you said there with my application, when the app crashes I
> see the address, I search for it and I see only one result, so I click the
> arrow next
Hello Corbin.
ok, so I read your blog post, its great, I love it.
I followed what you said there with my application, when the app crashes I see
the address, I search for it and I see only one result, so I click the arrow
next to the address to check the history and I have this situation.
firs
On Feb 18, 2010, at 12:29 AM, Ken Ferry wrote:
> On Wed, Feb 17, 2010 at 2:14 PM, Gustavo Pizano
> wrote:
>
> On Feb 17, 2010, at 11:03 PM, Jim Correia wrote:
>
> > On Feb 17, 2010, at 4:41 PM, Gustavo Pizano wrote:
> >
> >> Maybe I misunderstood I must conform NSCopying protocol also even wh
On Wed, Feb 17, 2010 at 2:14 PM, Gustavo Pizano wrote:
>
> On Feb 17, 2010, at 11:03 PM, Jim Correia wrote:
>
> > On Feb 17, 2010, at 4:41 PM, Gustavo Pizano wrote:
> >
> >> Maybe I misunderstood I must conform NSCopying protocol also even when
> using core data?
> >
> > If you have an NSCell sub
On Feb 17, 2010, at 2:14 PM, Gustavo Pizano wrote:
>
> On Feb 17, 2010, at 11:03 PM, Jim Correia wrote:
>
>> On Feb 17, 2010, at 4:41 PM, Gustavo Pizano wrote:
>>
>>> Maybe I misunderstood I must conform NSCopying protocol also even when
>>> using core data?
>>
>> If you have an NSCell subc
On Feb 17, 2010, at 11:03 PM, Jim Correia wrote:
> On Feb 17, 2010, at 4:41 PM, Gustavo Pizano wrote:
>
>> Maybe I misunderstood I must conform NSCopying protocol also even when using
>> core data?
>
> If you have an NSCell subclass which adds iVars, you must implement
> -copyWithZone: to do
On Feb 17, 2010, at 4:41 PM, Gustavo Pizano wrote:
> Maybe I misunderstood I must conform NSCopying protocol also even when using
> core data?
If you have an NSCell subclass which adds iVars, you must implement
-copyWithZone: to do correct memory management.
Your -copyWithZone: needs to work
Corbin Hi.
You may be right, Im not conforming NScopying protocol, but as I follow the
example in Tim's blog he din't also.
I read somewhere that one must do it when doing custom NSCells like my case,
but then somwhere in the botton said that when using core data you don't wanna
do that.
Thi
On Feb 17, 2010, at 12:16 PM, Gustavo Pizano wrote:
> Hello all.
>
> in My Core Data application I have a custom NSTableView with Custom NSCells
> inside because Im displaying the name of the user with the image of the user
> (the picture), its displaying fine, when selecting its selecting ok.
On Nov 25, 2009, at 3:25 PM, Ken Thomases wrote:
> You haven't retained this panel. If you want this object to live beyond the
> current autorelease context, you need to retain it. (Note that not retaining
> doesn't guarantee that it _will_ be released at the end of the autorelease
> context,
On Nov 23, 2009, at 6:51 PM, Darren Wheatley wrote:
> I have the following code as the action from a button click:
>
> - (IBAction)chooseFile:(id)sender;
> {
>NSOpenPanel *openPanel = [NSOpenPanel openPanel];
You haven't retained this panel. If you want this object to live beyond the
curre
On 24/11/2009, at 11:51 AM, Darren Wheatley wrote:
> - (IBAction)chooseFile:(id)sender;
> {
>NSOpenPanel *openPanel = [NSOpenPanel openPanel];
>[openPanel setCanChooseDirectories:NO];
>[openPanel setCanCreateDirectories:NO];
>[openPanel beginSheetForDirectory:nil
>
On Nov 23, 2009, at 4:51 PM, Darren Wheatley wrote:
> On my 10.6.2 iMac running XCode 3.2.1 it builds and runs fine. On my MacBook
> Pro with exactly the same OS version (10.6.2) and XCode version I get a crash
> - EXC_BAD_ACCESS when I run it.
Just the exception type isn't very useful. You sh
The only difference between the two machines is that the working machine
has DefaultFolderX installed on it.
As a test I installed Default Folder X on the MBP as well. The code now
runs without error.
So, why would Default Folder X be masking the problem (it overloads the
file open/save dial
Thanks a lot for the tip...
BTW, it's a RubyCocoa application. The case with zombie object was
hard to understand where does it come from...
since the object, that was reported was a ABMultiValueCoreDataWrapper
object, that was retained after it was released, but the stack showed
something
On Nov 10, 2009, at 8:56 PM, Nava Carmon wrote:
> Thank you Corbin for your great post.
>
> How do I track the following issue with instruments:
>
> *** attempt to pop an unknown autorelease pool
>
> ObjectAllocator with NSZombieEnabled doesn't react on this. I could track the
> same case you
Thank you Corbin for your great post.
How do I track the following issue with instruments:
*** attempt to pop an unknown autorelease pool
ObjectAllocator with NSZombieEnabled doesn't react on this. I could
track the same case you explained in your post, but it doesn't work
for pool autorele
On Nov 10, 2009, at 5:37 AM, Ian Piper wrote:
> Hi all,
>
> Can anyone advise a good strategy for tracking down EXC_BAD_ACCESS crashes? I
> have an application that I can run quite happily two out of three times. Then
> it will crash with this error. By this I mean I can do Build and Run
> su
To Jens and Ryan,
Thanks for the pointers - very helpful.
Ian.
--
___
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.
These might also be helpful:
http://www.cocoadev.com/index.pl?DebuggingTechniques (in particular see the
"Breaking on Exceptions" section where they talk about objc_exception_throw)
http://chanson.livejournal.com/171198.html
Then, when you crash, bring up the Debugger (Cmd-Shift-Y). Sometimes you
On Nov 10, 2009, at 5:37 AM, Ian Piper wrote:
Can anyone advise a good strategy for tracking down EXC_BAD_ACCESS
crashes? I have an application that I can run quite happily two out
of three times. Then it will crash with this error. By this I mean I
can do Build and Run successively with n
NSZombieEnabled should help track down your memory error.
http://www.cocoadev.com/index.pl?NSZombieEnabled
On Tue, Nov 10, 2009 at 8:37 AM, Ian Piper wrote:
> Hi all,
>
> Can anyone advise a good strategy for tracking down EXC_BAD_ACCESS crashes?
> I have an application that I can run quite happ
> I've come across a rather perplexing problem which is driving me nuts.
> I'm attempting to migrate a core data SQLite store to the current
> model version, and most of the time it works fine. However, sometimes
> I get an EXC_BAD_ACCESS in the following stack:
>
> objc_assign_strongCast +
On 10/28/09 10:48 AM, Daniel Kennett said:
>I've come across a rather perplexing problem which is driving me nuts.
>I'm attempting to migrate a core data SQLite store to the current
>model version, and most of the time it works fine. However, sometimes
>I get an EXC_BAD_ACCESS in the following sta
No, in GC a retain/release/autorelease always translates to a no-op.
An "id" or "SomeObject*" translates to a strong reference unless
specifically marked as weak.
So in the GC world, there is no difference between @property(retain)
and @property(assign), is there?
"If the object is in the g
On Wed, Oct 7, 2009 at 3:47 PM, Gabriel Zachmann wrote:
> In the doc of CALayer.contents it says
>
> @property(retain) id contents
>
> Does a retained property always translate to a strong reference in a GC
> environment?
No, in GC a retain/release/autorelease always translates to a no-op.
An "
Well, I did some more experimenting. Now I've got 2 issues ...
First of all, I guess I should apologize, because my minimal example
was not quite "minimal".
There was one other layer, which I have removed now. Now the code sort
of works in the GC world, *except* the memory footprint keeps g
On Oct 7, 2009, at 1:47 PM, Gabriel Zachmann wrote:
I did that and there is one sentence that I don't understand at all:
"CFMakeCollectable calls CFRelease, but has two supplementary
features: [...]; second, it’s a no-op in a reference counted
environment."
Shouldn't that be "a no-op in a
Thanks for the quick response.
I am still a bit confused ... and, besides, I still get a core dump ;-(
I think this is your problem right here. In a GC environment CALayer
isn't going to retain its content, it stores a strong reference
instead.
First of all, how can I know that? (I'm asking s
On Wed, Oct 7, 2009 at 1:13 PM, Gabriel Zachmann wrote:
> - (CALayer *) makeImageLayer: (NSString *) img_name inRect: (NSSize) size
> {
>// [snip]
> CGImageRef cgImage = CGImageSourceCreateImageAtIndex( sourceRef, 0, NULL
> );
>// [snip]
> imgLayer.contents = (id) cgImage;
>// [s
Eric Hermanson wrote:
3. Attempting to access or return a local variable that has not been
initialized (although you may get a segmentation fault instead of a
BAD_ACCESS, I can't remember). For example,
- (BOOL)someMethod
{
BOOL returnValue;
// code in the method that never sets the
On Fri, Sep 4, 2009 at 9:35 AM, Ian Piper wrote:
> I suppose that when I close the window it is released, so when I try to open
> it again there is nothing to open.
Yep. Common pitfall.
> 1. Why does a window default to having this option checked? It seems odd,
> since the auto-generated code se
On Sep 4, 2009, at 09:35, Ian Piper wrote:
I have been putting together a Core Data application that has three
windows. I wanted to control the appearance and disappearance of
these windows during the course of the application, so added menu
items and buttons with the action makeKeyAndOrder
In my experience this can happen for at least 3 reasons.
1. Over-releasing an object, as you state.
2. Sending a message to an object that has already been released (i.e.
deallocated).
3. Attempting to access or return a local variable that has not been
initialized (although you may get a
On Jul 4, 2009, at 11:43 PM, Andrew Farmer wrote:
- (int)numberOfSides {
return numberOfSides;
}
- (void)setNumberOfSides:(int)value {
numberOfSides = value;
}
Let me guess: does your stack trace (type "tb" in the gdb console)
indicate infinite recursion? Either synthe
On 4 Jul 2009, at 17:39, Ian Havelock wrote:
@synthesize numberOfSides;
@synthesize minimumNumberOfSides;
@synthesize maximumNumberOfSides;
- (int)numberOfSides {
return numberOfSides;
}
- (void)setNumberOfSides:(int)value {
numberOfSides = value;
}
Let me guess: does
On Jul 4, 2009, at 5:39 PM, Ian Havelock wrote:
For future reference, in many cases EXC_BAD_ACCESS can be indicative
of a memory management problem. Here, however, you are asking NSLog
to print int values as objects ('%@' is the format specifier for an
object):
NSLog(@"Number of Sides:
Hi, Ian,
From a cursory glance, the issue would likely be that you're using %@
in your NSLog statements, rather than %i or %d. %@ is used for
NSObjects, generally NSStrings. You'll want to replace that with %i
or %d since your -numberOfSides and other methods are returning int
values.
ple GC bug?
From: Ali Ozer
To: Chris Idou
Cc: Cocoa Dev
Sent: Tuesday, 31 March, 2009 4:12:55 PM
Subject: Re: EXC_BAD_ACCESS and NSAttributedString driving me crazy
Can you try temporarily disabling garbage collection around the
unarchiving of RTFD, and see if it helps?
[[NSGa
know I at least have a workaround.
Does this tend to indicate some kind of Apple GC bug?
From: Ali Ozer
To: Chris Idou
Cc: Cocoa Dev
Sent: Tuesday, 31 March, 2009 4:12:55 PM
Subject: Re: EXC_BAD_ACCESS and NSAttributedString driving me crazy
Can you try temporarily disabling garbage collec
On Mar 30, 2009, at 10:32 PM, Chris Idou wrote:
That's a good trick to know! When I bracket the calls thus, it
crashes in a different but similar place:
#00x95a82688 in objc_msgSend
#10x90894910 in processColor
#20x9089395b in CharAttr
#30x9088db34 in -[NSRTFReader attributedString]
#40x9070bc
, the crashes stop
happening. I'm relieved to know I at least have a workaround.
Does this tend to indicate some kind of Apple GC bug?
From: Ali Ozer
To: Chris Idou
Cc: Cocoa Dev
Sent: Tuesday, 31 March, 2009 4:12:55 PM
Subject: Re: EXC_BAD_
Can you try temporarily disabling garbage collection around the
unarchiving of RTFD, and see if it helps?
[[NSGarbageCollector defaultCollector] disable];
... unarchive your RTFD ...
[[NSGarbageCollector defaultCollector] enable];
Ali
On Mar 30, 2009, at 5:25 PM, Chris Idou wrote:
I'm gettin
to jump to the conclusion of
blaming Apple, if it wasn't that this API must be a very widely called one.
From: Sean McBride
To: Chris Idou ; cocoa-dev@lists.apple.com
Sent: Tuesday, 31 March, 2009 2:43:18 PM
Subject: Re: EXC_BAD_ACCESS and NSAttributedSt
1 - 100 of 125 matches
Mail list logo
