On Mon, Jan 13, 2014 at 09:51:38AM +0200, Michał Sawicz wrote:
> On 12.01.2014 21:48, Steve Langasek wrote:
> >Ok. I don't see any reason that the kill timeout would be insufficient for
> >this case. Tested in a user session with the attached python program and
> >upstart job, and I get the expec
On Fri, Jan 10, 2014 at 8:04 PM, Steve Langasek
wrote:
> On Fri, Jan 10, 2014 at 10:10:14AM +, Evan Dandrea wrote:
>> There's a deeper problem here. Didier informs me that they were seeing
>> a lot of crashes in unity8 with a smashed stacktrace. They realised
>> the dying unity process was get
On 12.01.2014 21:48, Steve Langasek wrote:
Ok. I don't see any reason that the kill timeout would be insufficient for
this case. Tested in a user session with the attached python program and
upstart job, and I get the expected results in
~/.cache/upstart/kill-test.log.
Maybe the kill timeout i
On Sat, Jan 11, 2014 at 12:00:45AM +0100, Michał Sawicz wrote:
> On 10.01.2014 23:58, Steve Langasek wrote:
> >Oh, ok - yes, dying with SIGSEGV after receiving SIGTERM from upstart would
> >certainly trigger that behavior.
> >Is the SIGTERM being sent because the user session is exiting? If so,
>
On 10.01.2014 23:58, Steve Langasek wrote:
Oh, ok - yes, dying with SIGSEGV after receiving SIGTERM from upstart would
certainly trigger that behavior.
Is the SIGTERM being sent because the user session is exiting? If so,
overriding the kill timeout may not be enough, because upstart will also
On Fri, Jan 10, 2014 at 11:24:52PM +0100, Michał Sawicz wrote:
> On 10.01.2014 20:04, Steve Langasek wrote:
> >I don't see how this analysis can be correct. upstart receives no signal
> >from the kernel that the process has died until after the core handler is
> >finished, and if the unity8 proces
On 10.01.2014 20:04, Steve Langasek wrote:
I don't see how this analysis can be correct. upstart receives no signal
from the kernel that the process has died until after the core handler is
finished, and if the unity8 process has died with a segfault there's no
process for upstart to kill anyway
On Fri, Jan 10, 2014 at 10:10:14AM +, Evan Dandrea wrote:
> There's a deeper problem here. Didier informs me that they were seeing
> a lot of crashes in unity8 with a smashed stacktrace. They realised
> the dying unity process was getting reaped and restarted by upstart
> while still being proc
We do clean out /var/log/crashes both at the beginning before a test
as run, as well as after uploading crashes. I agree, it's very
unlikely that the crash itself has anything to do with running click
list --manifest, but it's not unheard of to see crashes that happen
not because of the test runnin
On 10/01/14 02:23, Paul Larson wrote:
= Mako =
100% pass (no reruns for anything)
But we saw several crashes - dialer-app (which has been going on for a
while) as well as unity8 crash in default and in click-image-tests.
Default tests also saw a crash in whoopsie:
http://ci.ubuntu.com/smokeng/tr
Evan Dandrea [2014-01-10 10:10 +]:
> The phone does not presently do a second-phase processing of crash
> files (adding package information, hooks, etc)
Not the one itself, but our CI test machinery is doing that. It calls
/usr/share/apport/whoopsie-upload-all after running the tests, which
d
On 10 January 2014 09:15, Alexander Sack wrote:
> On Fri, Jan 10, 2014 at 6:23 AM, Paul Larson
> wrote:
>> = Mako =
>> 100% pass (no reruns for anything)
>> But we saw several crashes - dialer-app (which has been going on for a
>> while) as well as unity8 crash in default and in click-image-test
On Fri, Jan 10, 2014 at 6:23 AM, Paul Larson wrote:
> = Mako =
> 100% pass (no reruns for anything)
> But we saw several crashes - dialer-app (which has been going on for a
> while) as well as unity8 crash in default and in click-image-tests.
> Default tests also saw a crash in whoopsie:
> http://
On 10.01.2014 06:23, Paul Larson wrote:
as well as unity8 crash in default and in click-image-tests.
The two .crash files in click-image-tests were not pre-processed by
apport, any idea why? Hmm it seems they're corrupted - apport-cli fails
to process them.
The one in default is the usual:
= Mako =
100% pass (no reruns for anything)
But we saw several crashes - dialer-app (which has been going on for a
while) as well as unity8 crash in default and in click-image-tests.
Default tests also saw a crash in whoopsie:
http://ci.ubuntu.com/smokeng/trusty/touch/mako/120:20140109.1:20140107.1
15 matches
Mail list logo
