Re: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

> On 2016 Dec 7, at 6:27, Carl Hoefs wrote: > >> >> On Dec 6, 2016, at 1:33 PM, Carl Hoefs >> wrote: >> >>> On Dec 6, 2016, at 1:24 PM, David Duncan wrote: >>> >>> Your safest bets are to either clear the delegate of the layer at an >>> appropriate time (possibly in your view controller’s

Re: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

> On Dec 6, 2016, at 1:33 PM, Carl Hoefs wrote: > >> On Dec 6, 2016, at 1:24 PM, David Duncan wrote: >> >> Your safest bets are to either clear the delegate of the layer at an >> appropriate time (possibly in your view controller’s dealloc is all that is >> necessary), or to use a UIView ins

Re: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

> On Dec 6, 2016, at 1:24 PM, David Duncan wrote: > > Your safest bets are to either clear the delegate of the layer at an > appropriate time (possibly in your view controller’s dealloc is all that is > necessary), or to use a UIView instead of a raw CALayer in this case. > Removing the layer

Re: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

er]; >> >> Upon dismissing the VC: >> >> [self dismissViewControllerAnimated:YES completion:nil]; >> >> The following exception occurs: >> >> (lldb) bt >> * thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, >> qu

Re: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

llowing exception occurs: > > (lldb) bt > * thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, > queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, > address=0xb010) >frame #0: 0x22c2c68a libobjc.A.dylib`objc_retain

Re: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

_layer]; >> >> Upon dismissing the VC: >> >> [self dismissViewControllerAnimated:YES completion:nil]; >> >> The following exception occurs: >> >> (lldb) bt >> * thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, >>

Re: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

gt; The following exception occurs: > > (lldb) bt > * thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, > queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, > address=0xb010) >frame #0: 0x22c2c68a libobjc.A.dylib`objc_retain +

iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

ain-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xb010) frame #0: 0x22c2c68a libobjc.A.dylib`objc_retain + 10 frame #1: 0x27a2a22a UIKit`-[UIView(Hierarchy) subviews] + 330 frame #2: 0x27b3e1ea UIKit`discardEngineRecursive + 118 frame #3: 0x27a2fd06 UIKit`-[UIView

Re: EXC_BAD_ACCESS puzzle when not running as test bundle

y when built on 10.11. > I have set up a simple test scenario and it boils down to the following. > If I execute the same 4 line test code as part of a unit test bundle it works > fine. > If I try and execute the exact same code as part of a foundation tool then it > crashes with EXC_BA

EXC_BAD_ACCESS puzzle when not running as test bundle

a foundation tool then it crashes with EXC_BAD_ACCESS. The actual code is calling down into Mono and the crash is associated with the AOT compiler (my Cocoa code provides a wrapper to Mono). So there is plenty there that could be going askew on 10.11. However the fact that the code executes

Re: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000bbadbeef crash on UIWebview

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

Re: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000bbadbeef crash on UIWebview

lso 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 22 Jun 2015, at 09:21, Devarshi Kulshreshtha < > devarshi.bluec...@gmail.com> wrote: > > > > Here

Re: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000bbadbeef crash on UIWebview

? > On 22 Jun 2015, at 09:21, Devarshi Kulshreshtha > wrote: > > Here is my viewDidLoad method: > > EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0xbbadbeef > > - (void)viewDidLoad { >[super viewDidLoad]; > >[self setTitle:[self.parameters_ get:@"t

EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000bbadbeef crash on UIWebview

Here is my viewDidLoad method: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0xbbadbeef - (void)viewDidLoad { [super viewDidLoad]; [self setTitle:[self.parameters_ get:@"title"]]; whiteBGLayer = [[CALayer alloc] init]; [whiteBGLayer setBackgroundColor:[UIColor

Re: performBatchUpdates: + removeObjectAtIndex: = EXC_BAD_ACCESS

I suspect your code is getting called on multiple threads, which would definitely cause crashes or heap corruption since you haven't added any synchronization around your objects. If you don't explicitly use multiple threads, maybe the UICollectionView is running your performBatchUpdates: block

performBatchUpdates: + removeObjectAtIndex: = EXC_BAD_ACCESS

Hi everyone, I'm getting an EXC_BAD_ACCESS from my specific combination of performBatchUpdates: and removeObjectAtIndex:. The application is within a framework I'm developing. The framework has a Mediator object, and multiple Manager dependencies. The Mediator combines input from

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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)

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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 >>

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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. Ple

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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)

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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...

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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,

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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

Re: EXC_BAD_ACCESS in NSData

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,

EXC_BAD_ACCESS in NSData

[datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; // Packet content 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

EXC_BAD_ACCESS in NSData

[datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; // Packet content 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

EXC_BAD_ACCESS signal in Core Data app on Lion 10.7.4

i’m getting an EXC_BAD_ACCESS crash in my app when it runs under lion 10.7.4. the app runs fine on 10.6.8. the app is built with xCode 3.2.6 on lion, using the 10.6 sdk and targeting 10.6. this is 100% repeatable. when the user executes a menu item, i execute a bunch of code that includes

Re: Help debugging EXC_BAD_ACCESS

d implemented? > > On 5 Apr 2012, at 01:09, Rick Mann wrote: > >> This is odd. I have an app that downloads locations from a web service, and >> creates NSManagedObejct (subclass: Location) for them. It's been working >> fine on simulator and device. Sudde

Re: Help debugging EXC_BAD_ACCESS

them. It's been working fine > on simulator and device. Suddenly, I get a consistent EXC_BAD_ACCESS on > device and simulator every time I create a new location (existing locations > in the store work fine. > > Here's the code snippet: > >[NSO

Help debugging EXC_BAD_ACCESS

This is odd. I have an app that downloads locations from a web service, and creates NSManagedObejct (subclass: Location) for them. It's been working fine on simulator and device. Suddenly, I get a consistent EXC_BAD_ACCESS on device and simulator every time I create a new location (exi

Re: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

On Feb 20, 2012, at 10:16 AM, Matt Neuburg wrote: > On Fri, 17 Feb 2012 16:06:01 -0800, Greg Parker said: >> No. objc_msgSend() also reads from the class's method cache and method list. >> It's possible for the receiver object to be valid, but still crash because >> of a memory smasher that hit

Re: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

On Fri, 17 Feb 2012 16:06:01 -0800, Greg Parker said: >Those of us who wrote objc_msgSend() can sometimes track down the >problem by finding which data structure was damaged and examining the >bad data. Everyone else should try Zombies, Guard Malloc, and Malloc Scribble. And valgrind... if it wor

Re: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

On Fri, 17 Feb 2012 16:06:01 -0800, Greg Parker said: >No. objc_msgSend() also reads from the class's method cache and method list. >It's possible for the receiver object to be valid, but still crash because of >a memory smasher that hit the method cache or method list It's also possible for th

Re: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

On Feb 17, 2012, at 2:02 PM, Jerry Krinock wrote: > On 2012 Feb 17, at 09:54, Kyle Sluder wrote: >> All that means is that the storage for the object hasn't been overwritten >> yet. > > Thank you, Kyle, and I see what you mean. But also my tests show that the > object is still able to respond t

Re: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

On 2012 Feb 17, at 09:54, Kyle Sluder wrote: > All that means is that the storage for the object hasn't been overwritten yet. Thank you, Kyle, and I see what you mean. But also my tests show that the object is still able to respond to messages, which means that it shouldn't have crashed objc_

Re: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

On Fri, Feb 17, 2012 at 8:53 AM, Jerry Krinock wrote: > > Both the receiver (a window controller) and the method's parameter (a timer) > both seem to be good, live, valid objects… > > (gdb) po 0xcdbf570 > > (gdb) po [0xcdbf570 window] > > (gdb) po 0x9315960 > <__NSCFTimer: 0x9315960> > (gdb) po

How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

I got an EXC_BAD_ACCESS in objc_msgSend. By probing registers in gdb, I am able to get the receiver, selector and the single parameter of the offending message. (gdb) po *(int*)($ebp+8) (gdb) po NSStringFromSelector(*(int*)($ebp+12)) updateAgentActivityNow: (gdb) po *(int*)($ebp+16

Re: Return causes EXC_BAD_ACCESS

On Jul 31, 2011, at 8:27 AM, Scott Ribe wrote: > No, fork copies the entire address space when it is called, but vfork works > as he described. In neither case will modifications to memory by one process > by visible by the other. Oh, hogwash. Of course copy-on-write is a common optimization to

Re: Return causes EXC_BAD_ACCESS

On Jul 31, 2011, at 1:59 AM, vincent habchi wrote: > Thanks for these precisions. Actually, you’re right with fork (2), but vfork > (2), AFAIK, does not copy anything; note that I’m aware that vfork usually is > meant to be immediately followed by exec (3). No, fork copies the entire address sp

Re: Return causes EXC_BAD_ACCESS

Le 31 juil. 2011 à 09:27, Ron Hunsinger a écrit : > When a process forks, the child and parent get different virtual memory maps > that, for the time being, happen to point to the same physical memory pages. > The sharing is an implementation detail, for optimization. Conceptually, the > parent

Re: Return causes EXC_BAD_ACCESS

On Jul 31, 2011, at 12:27 AM, Ron Hunsinger wrote: > The point vincent was making was ... Sorry for the misattribution. I meant "The point Graham Cox and Scott Ribe were making was ...". ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please

Re: Return causes EXC_BAD_ACCESS

pace. The other methods you mention of sharing memory are by special arrangement, and rarely used (although extremely useful when they are). The point vincent was making was to correct the OP's belief that a random pointer (0x18c95b0 was the example mentioned) pointed to some memory somewhere

Re: Return causes EXC_BAD_ACCESS

> Memory is "virtual", the addresses you appear to be working with are not real > (i.e. they don't refer to the real address of the physical RAM underneath). > Instead, a bit of hardware translates these to the real addresses as needed > at some level far below the perception of your program. Yo

Re: Return causes EXC_BAD_ACCESS

On 29/07/2011, at 7:33 AM, Mr. Gecko wrote: > From my understanding, this should happen when you, for an example, try to > access the pointer 0x18c95b0 whenever that belongs to another process. No. Memory is "virtual", the addresses you appear to be working with are not real (i.e. they don't

Re: Return causes EXC_BAD_ACCESS

On Jul 28, 2011, at 3:00 PM, Kyle Sluder wrote: > I'm not sure what your motivation is for calling [self release] here, > but no code should be doing this. I disagree. There are a couple of reasons to call this: - It’s pat of the failure path for -init methods. Before returning nil you need to

Re: Return causes EXC_BAD_ACCESS

On Jul 28, 2011, at 3:33 PM, Mr. Gecko wrote: > From my understanding, this should happen when you, for an example, try to > access the pointer 0x18c95b0 whenever that belongs to another process. > However, I also thought that the Mac has a copy of memory space for each > process and therefore

Re: Return causes EXC_BAD_ACCESS

Well, let's think about it. "Instance variables" are only accessible as long as you have an instance, right? You can't have an instance variable without an instance. So if you set "self" to nil... then you no longer have an instance. Thus, you cannot access self's instance variables, because

Re: Return causes EXC_BAD_ACCESS

On Thu, Jul 28, 2011 at 2:45 PM, Mr. Gecko wrote: > That makes lots of sense, never even expected that to happen. Adding a local > variable and setting it to the value before releasing it and returning that > variable fixes the issue. I am still looking to an link to explanation in > detail as

Re: Return causes EXC_BAD_ACCESS

That makes lots of sense, never even expected that to happen. Adding a local variable and setting it to the value before releasing it and returning that variable fixes the issue. I am still looking to an link to explanation in detail as to why this happens. If it's as I said, then I do not think

Re: Return causes EXC_BAD_ACCESS

It kind of looks like foundCookieJar is an ivar, which means that "return foundCookieJar" is really going to be "return self->foundCookieJar". Since you set "self" to "nil", you're trying to dereference a NULL pointer, which is a great way to crash your app. HTH, Dave On Jul 28, 2011, at 2:3

Return causes EXC_BAD_ACCESS

I am unable to find out as to why I am receiving this problem, I can verify other parts of the code before it gets to the return and that the object I am returning does in-fact work as I am able to NSLog it and see the description of it. The basic idea of this code is to notify other objects to

Re: EXC_BAD_ACCESS in NSApplicationMain

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_exception_throw” and “[NSException raise]“. Any idea how to get beyond t

Re: EXC_BAD_ACCESS in NSApplicationMain

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 &g

Re: EXC_BAD_ACCESS in NSApplicationMain

v=0x7fff5fbff5c0) at main.m:13 > (gdb) I started seeing this in Xcode 4.1 and 4.2 too. -- Tito On Jul 24, 2011, at 7:50 PM, 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 i

EXC_BAD_ACCESS in NSApplicationMain

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_exception_throw” and “[NSException raise]“. Any ide

EXC_BAD_ACCESS searching PDF

___ 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

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

Thanks, all. Quincey, the three Error Points you defined are great. Fortunately, in this case I have the easy one… On 2011 May 29, at 13:03, Quincey Morris wrote: > Error point #2 (super returns nil) is easy. Just return nil. because one should assume that the superclass will have cleaned up a

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

On May 29, 2011, at 12:57, Ken Thomases wrote: > But it's important to recognize that there are good arguments on both sides > and the design decision involved a tradeoff. In any case, it doesn't seem to > me that that design decision necessarily implies that calling super with a > nil self sh

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

On May 29, 2011, at 12:20, Jerry Krinock wrote: > - (id)initWithDocUuid:(NSString*)docUuid { >NSManagedObjectContext* moc ; >moc = [[BkmxBasis sharedBasis] exidsMocForIdentifier:docUuid] ; > >self = [super initWithManagedObjectContext:moc >entityNam

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

On May 29, 2011, at 2:43 PM, Quincey Morris wrote: > The difference in the second case is that the compiler translates it (AFAIK) > into a call to objc_msgSendSuper instead of objc_msgSend. What I'm winding up > to here is that the failure in messaging a nil 'super' looks to me like a bug > in

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

On May 29, 2011, at 2:20 PM, Jerry Krinock wrote: > So, let's look at the subclass init method which invokes -dealloc: > > - (id)initWithDocUuid:(NSString*)docUuid { >NSManagedObjectContext* moc ; >moc = [[BkmxBasis sharedBasis] exidsMocForIdentifier:docUuid] ; > >self = [super initW

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

On May 29, 2011, at 12:20, Jerry Krinock wrote: > Ah, I get it now. It's the access to the pointer m_managedObjectContext > itself that's the problem. > > So, let's look at the subclass init method which invokes -dealloc: > > - (id)initWithDocUuid:(NSString*)docUuid { >NSManagedObjectConte

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

>> NSLog(@"0988 %p %s", self, __PRETTY_FUNCTION__) ; >> NSLog(@"1250 ") ; >> CRASH-> int myPointer = (int)m_managedObjectContext ; >> NSLog(@"1335 myPointer = %d", myPointer) ; >> ... >> } >> >

Re: How can logging a pointer value cause EXC_BAD_ACCESS?

   NSLog(@"1250 ") ; > CRASH->   int myPointer = (int)m_managedObjectContext ; >          NSLog(@"1335 myPointer = %d", myPointer) ; >          ... >      } > > stderr output: > > 0988 0x0 -[SSYMojo dealloc] > 1250 > Program received signal:  “EXC_BAD_ACC

How can logging a pointer value cause EXC_BAD_ACCESS?

ext ; NSLog(@"1335 myPointer = %d", myPointer) ; ... } stderr output: 0988 0x0 -[SSYMojo dealloc] 1250 Program received signal: “EXC_BAD_ACCESS” The line marked CRASH-> is highlighted in blue by Xcode/gdb. How can this crash? I wanted to log the pointer value (a

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

On Wed, 16 Feb 2011 11:17:27 -0800, Keith Blount said: >The debugging continues... You could try valgrind too: It works decently on Mac OS now (though no Obj-C GC support still)... -- Sean McBride

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

aced all of the code and the problem document that seemed to be triggering the crash into the separate app... And of course it refused to crash. The debugging continues... Thanks again! All the best, Keith --- On Wed, 2/16/11, Bruce Cresanta wrote: > From: Bruce Cresanta > Subject: Re

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

nextEventMatchingMask:untilDate:inMode:dequeue:] #261981 0x93b5c247 in -[NSApplication run] #261982 0x93b542d9 in NSApplicationMain #261983 0x0003513a in main at main.m:23 // #261971 0x98d33c6d in _CFAutoreleasePoolPop results in EXC_BAD_ACCESS when you release a variable marked as autorelease. Go back

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

being written into /tmp/stack-logs.7728.tar.XYgOka.index tar(7728) malloc: stack logs deleted from /tmp/stack-logs.7728.tar.XYgOka.index Program received signal: “EXC_BAD_ACCESS”. (I have MallocStackLogging turned on as well as NSZombieEnabled.) And the backtrace doesn't help either: #261

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

On Tue, 15 Feb 2011 12:41:51 -0800, Keith Blount said: >I'm trying to debug an EXC_BAD_ACCESS crash in my application and am >tearing my hair out trying to find the cause. I have NSZombieEnabled set >to YES, but this isn't providing me with any information (using >NSZombieEn

Tracking a EXC_BAD_ACCESS when zombies don't work

Hello, I'm trying to debug an EXC_BAD_ACCESS crash in my application and am tearing my hair out trying to find the cause. I have NSZombieEnabled set to YES, but this isn't providing me with any information (using NSZombieEnabled is always one of the first things I try with crashes

Re: EXC_BAD_ACCESS when loading nib

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

EXC_BAD_ACCESS when loading nib

p finishes launching, I get: Program received signal: “EXC_BAD_ACCESS”. Looking at the stack, I see: #0 0x902a1a76 in _PFFastEntityRangesByType #1 0x902e3028 in _PF_ManagedObject_WillChangeValueForKeyIndex #2 0x902e59d6 in -[NSManagedObject willChangeValueForKey:] #3 0x9

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

mouse over _record to see its state (yellow pop-up views, with expansions arrows, the same info you can get from debugger window). And, surprise! _attributes points to a NSEvent instance!!! Though _attributes was obtained calling attributesOfItemAtPath:error:, no error was produced, and I retained i

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

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

  1   2   3   4   >