Re: advanced debugging?
Re: advanced debugging?
- Subject: Re: advanced debugging?
- From: Michael David Crawford <email@hidden>
- Date: Wed, 14 Oct 2015 20:25:12 -0700
I expect that bug was there, before you added the web view, but
something about removing the web view led a previously-latent bug to
become active.
Try bisecting your code, that is, remove half your source, try to
reproduce the bug, then put that first half back in and remove the
other half. Now remove just a quarter.
Also add lots of assertions. Leave the assertions in even after
you've found your bug, likely the assertion will catch some other bug
right away. For me they are most effective at validating subroutine
parameters; a pointer is often permitted to be NULL but sometimes may
not be:
#import <assert.h>
- (id) foo( char *p )
{
assert( p != NULL );
...
}
Many classes have invariants; suppose a Square is a subclass of
Rectangle. Rectangles have the invariant that their corners are all
ninety degree angles while Squares have that same invariant but also
the sides of Square are always equal - or the same within a very small
tolerance, such as less than a point or a pixel.
Can you construct input data that either does or does not stimulate bugs?
Read Robert Ward's "Debugging C" or his second edition "A Programmer's
Introduction to Debugging C".
Most importantly be methodical. Even if you cannot see your way
clear, don't thrash around mindlessly.
Michael David Crawford, Baritone
email@hidden
One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light.
On Wed, Oct 14, 2015 at 7:32 PM, Jens Alfke <email@hidden> wrote:
>
>> On Oct 14, 2015, at 7:08 PM, Alex Hall <email@hidden> wrote:
>>
>> Unfortunately this didn't reveal much of anything that I can tell. It goes straight from
>> 5 Array.append<A>(A) -> (),
>> to
>> 0 swift_slowAlloc,
>> and that's it. Well, there's more before that, but nothing after. I guess I was hoping for a line number in a specific file, but maybe there's no way to get that specific? Or am I looking at the wrong stack trace?
>
> swift_slowAlloc must be the function that directly called malloc with the huge number. That’s why there’s nothing after it.
>
> The culprit is probably before the first frame you listed. My guess is that someone’s trying to append a ridiculous number of items to an array, such that the new size of the array is that huge number mentioned in the malloc warning. So what’s further down the stack? Any of your code?
>
> —Jens
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden