Ray Wenderlich's website has a guide on tracking down SIGABRTs, it might
help. It's a two part guide, for the second part just change the "1" at the
end of the link to "2"
http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-1
On Mon, Apr 30, 2012
On Apr 30, 2012, at 12:00 PM, Jens Alfke wrote:
> On Mac OS the system will also put up the standard crash alert, whereas a
> call to abort() (which is what assert() calls) just makes the app vanish with
> no explanation to the user.
Depends on the version perhaps? I certainly see abort() putti
On Apr 30, 2012, at 11:00 AM, Jens Alfke wrote:
> On Apr 29, 2012, at 8:00 PM, Don Quixote de la Mancha wrote:
>> Place some assertions as the very first executable lines in each of
>> your subroutines.
> ...
>> #include
>>
>> void foo( int *ptr )
>> {
>> assert( NULL != ptr );
>
> Ouch. Don’t
>> void foo( int *ptr )
>> {
>> assert( NULL != ptr );
>
>Ouch. Don't use this in a Cocoa app; use NSAssert and NSParameterAssert
>instead. You'll get much better reporting of the error, because you can
>use custom messages with parameters, and the app will raise an exception
>and log the backtra
On Apr 29, 2012, at 8:00 PM, Don Quixote de la Mancha wrote:
> Place some assertions as the very first executable lines in each of
> your subroutines.
...
> #include
>
> void foo( int *ptr )
> {
> assert( NULL != ptr );
Ouch. Don’t use this in a Cocoa app; use NSAssert and NSParameterAssert
On Apr 29, 2012, at 7:50 PM, Alex Zavatone wrote:
> I've had the joy of trying to reassemble my app which a co worker improved
> last week by moving it to storyboarding. What's popping up every now and
> then as I try to wire views together are instant SIGABRTs with no indication
> why this i
On Sun, Apr 29, 2012 at 8:00 PM, Don Quixote de la Mancha
wrote:
> Place some assertions as the very first executable lines in each of
> your subroutines. The chances are quite good that the cause of the
> SIGABRTs are executable quite a long time before the crashes actually
> happen.
...
> #incl
Ahh. Well, I changed it back from HIPAppDelegate to AppDelegate and when the
SIGABRT happens, the catch isn't catching it. I set a breakpoint on NSLog and
it's never triggered.
Am I assuming too much here?
On Apr 29, 2012, at 11:35 PM, Roland King wrote:
> That's autogenerated code, came fr
That's autogenerated code, came from the project template.
On Apr 30, 2012, at 11:33 AM, Alex Zavatone wrote:
>
> On Apr 29, 2012, at 11:26 PM, Roland King wrote:
>
>> At least during development I do this to main.m
>>
>> int main(int argc, char *argv[])
>> {
>> @autoreleasepool {
>>
On Apr 29, 2012, at 11:26 PM, Roland King wrote:
> At least during development I do this to main.m
>
> int main(int argc, char *argv[])
> {
> @autoreleasepool {
> @try
> {
> return UIApplicationMain(argc, argv, nil,
> NSStringFromClass([H
At least during development I do this to main.m
int main(int argc, char *argv[])
{
@autoreleasepool {
@try
{
return UIApplicationMain(argc, argv, nil,
NSStringFromClass([HIPAppDelegate class]));
}
@ca
I had the same thing Friday night or last night too.
I ended up creating a new TVC, moving pieces in one at a time and in one case,
it was the table cell name not matching.
Now, I've gotten an empty TVC to work, so it's move the pieces in one at a time
again.
There are no errors when I p
It sounds to me like your xib (nib) file has been "corrupted". For example,
it's possible that you have somehow destroyed, say, a link between an object
(view?) and its counterpart in your implementation or a link between an object
like a button or a textfield and it's IBAction.
I suggest that
On Sun, Apr 29, 2012 at 7:50 PM, Alex Zavatone wrote:
> I've had the joy of trying to reassemble my app which a co worker improved
> last week by moving it to storyboarding. What's popping up every now and
> then as I try to wire views together are instant SIGABRTs with no indication
> why thi
I've had the joy of trying to reassemble my app which a co worker improved last
week by moving it to storyboarding. What's popping up every now and then as I
try to wire views together are instant SIGABRTs with no indication why this is
happening.
I'm currently stuck going from a TableViewCont
15 matches
Mail list logo
