> On Oct 14, 2015, at 22:32, Jens Alfke <[email protected]> wrote:
> 
> 
>> On Oct 14, 2015, at 7:08 PM, Alex Hall <[email protected]> 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?

You're right, though it makes no sense. I update five arrays in viewDidLoad, 
all of them asynchronously. Each works at first--the tweets to add to the 
arrays are called, because each update prints to the console that it has 
started. Then, when the first array is about to be updated, it looks like this 
breaks. Here's the handler that gets called to do the job:

                let successHandler = {
                        (statuses:[JSONValue]?) in
                        if let unwrappedStatuses=statuses {
                                print("Got \(unwrappedStatuses.count) new 
tweets.") //this prints "got 48 new tweets"
                                for status in unwrappedStatuses { 
self.addTweetWithJSONValue(status) }
                        } else { //nil was returned
                                print("New statuses was nil.")
                        }
                }

As the comment says, this works perfectly, and tries to add 48 items, not the 
astoundingly large number the error complains about. At least now I have a 
better handle on that stack; I was so focused on the now-removed web view being 
the problem I tried to make the stack trace fit that pattern, which it doesn't. 
Why it pointed here I have no clue, but at least I'm one step closer.

For these stack traces, is there any way for it to point right at the offending 
line in context? That is, instead of a generic array.append call, could it say 
line 119 in MyModel.swift, or wherever the problem is?
> —Jens


--
Have a great day,
Alex Hall
[email protected]

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to