Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of shazron@gmail.com designates
 209.85.216.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CD4D1790.185CF%fil@adobe.com>
References: 
 <CAEeF2TcqUTbYFgWTTkmXmJnRvx50NAoQzrUYX9nxYXtaN7T=pA@mail.gmail.com>
 <CD4D1790.185CF%fil@adobe.com>
From: Shazron <shazron@gmail.com>
Date: Fri, 22 Feb 2013 14:24:00 -0800
Message-ID: 
 <CAE6O_-a0XCABvQsc0AuabfFOa+83w2NL1cMfEynrPD-s=aJo2A@mail.gmail.com>
Subject: Re: [iOS] Crash on 5.1.1 with recent commits
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=20cf3074d5744ab1cc04d657a866

--20cf3074d5744ab1cc04d657a866
Content-Type: text/plain; charset=ISO-8859-1

For iOS, this might get too chatty if we send emails to the list since
every run will produce an error because of the Location permissions timeout
thing that we can't overcome. So if we do N commits a day (assuming
ci.cordova.io builds on every new commit), we will get N emails. I suppose
we could filter out timeouts as 'warnings' or something (not sure if that
is supported on jasmine)


On Fri, Feb 22, 2013 at 12:41 PM, Filip Maj <fil@adobe.com> wrote:

> Sounds like a good idea! I've got related issues set up:
>
> - On a timeout for running mobile-spec (which would have caught this
> error), post an ERROR https://github.com/filmaj/medic/issues/20
> - review how errors are shown in the dashboard
> https://github.com/filmaj/medic/issues/22
>
> Perhaps I add one that the dashboard triggers an e-mail to the dev list
> every time medic experiences an error?
>
> On 2/22/13 12:37 PM, "Michal Mocny" <mmocny@chromium.org> wrote:
>
> >+100
> >
> >
> >On Fri, Feb 22, 2013 at 3:35 PM, Shazron <shazron@gmail.com> wrote:
> >
> >> I love http://ci.cordova.io :)
> >> Feature request: e-mail a committer on failure
> >>
> >>
> >> On Fri, Feb 22, 2013 at 12:31 PM, Filip Maj <fil@adobe.com> wrote:
> >>
> >> > I was noticing the device wall was running tests on all iOS devices
> >>fine
> >> > except for the 5.1.1 iPod.
> >> >
> >> > Now I need medic to catch this issue on show it up on the dashboard..
> >> > Always work to do :)
> >> >
> >> > On 2/22/13 12:22 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >> >
> >> > >Thanks for the catch! (and useful stack trace)
> >> > >
> >> > >Looks like I accidentally checked in a change I shouldn't have:
> >> > >
> >> > >-    [self evalJsHelper:js];
> >> > >+    [self evalJsHelper2:js];
> >> > >
> >> > >
> >> > >
> >> > >On Fri, Feb 22, 2013 at 3:15 PM, Filip Maj <fil@adobe.com> wrote:
> >> > >
> >> > >> This is the output I get about 20 or so tests into the full jasmine
> >> unit
> >> > >> test:
> >> > >>
> >> > >> 2013-02-22 12:12:58.748 cordovaExample[4857:3107] bool
> >> > >> _WebTryThreadLock(bool), 0x2aeb40: Tried to obtain the web lock
> >>from a
> >> > >> thread other than the main thread or the web thread. This may be a
> >> > >>result
> >> > >> of calling to UIKit from a secondary thread. Crashing now...
> >> > >> 1   _ZL17_WebTryThreadLockb
> >> > >> 2   WebThreadLock
> >> > >> 3   -[UIWebView stringByEvaluatingJavaScriptFromString:]
> >> > >> 4   -[CDVCommandDelegateImpl evalJsHelper2:]
> >> > >> 5   -[CDVCommandDelegateImpl sendPluginResult:callbackId:]
> >> > >> 6   __22-[CDVContacts search:]_block_invoke_2
> >> > >> 7   -[CDVAddressBookHelper createAddressBook:]
> >> > >> 8   __22-[CDVContacts search:]_block_invoke
> >> > >> 9   _dispatch_call_block_and_release
> >> > >> 10  _dispatch_worker_thread2
> >> > >> 11  _pthread_wqthread
> >> > >> 12  start_wqthread
> >> > >>
> >> > >>
> >> > >> Passes fine on 6.0.1 devices (both iphone5 and iPod).
> >> > >>
> >> > >> Fails on ipod4,1 running 5.1.1.
> >> > >>
> >> > >>
> >> >
> >> >
> >>
>
>

--20cf3074d5744ab1cc04d657a866--