Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linuxtools-dev] [Hudson] Hudson build became unstable: linuxtools-luna #9

Thanks Andrew for looking further into this. I haven't had the time to
track down the real problem. From what I can tell in the git history,
this could be related to this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=327497
and this commit:
http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=0643c40412ead265c6679ad608f2e8fceb7f15e9

If you feel pretty confident it's a platform bug, maybe it would be good
to put your findings in this bugzilla so that the debug team can know
earlier that there is a potential regression. The last build for the
Eclipse Platform is Thursday I believe ;)

Marc-Andre

On 14-06-02 04:29 PM, Andrew Ferrazzutti wrote:
> I've been using Maven debugging to examine the failing tests, and found
> that the failure we're getting is being caused by changes to
> SourceLookupFacility (in org.debug.internal). It has been changed to
> cache the results of previous source lookups, mapping artifacts (source
> identifiers) to SourceLookupResults. With the way the memcheck tests are
> using it, though, artifacts are just file name strings, so any two files
> with the same name will have the same lookup result [1].
>
> More specifically, our failures occur during the source lookup stage of
> the Valgrind launch config delegate [2]. The tests that run before the
> failing ones launch a file named "test.c" in a project named
> "basicTest", and source lookup succeeds for them & get cached. However,
> any extension of AbstractLinkedResourceMemcheckTest creates a
> differently-named project, "linkedTest", but still launches a file named
> "test.c". This means that the previous cached lookup results for the old
> "test.c" files will be used for this new file, meaning its parent
> project will be improperly believed to be "basicTest" (which is deleted
> by the time the new tests run). This also explains why basicTest appears
> in the test failure logs despite it not being used explicitly anywhere
> in the failing tests.
>
> This is almost certainly qualifies as a platform bug, but I'll look into
> it a bit more before posting it on EBZ in case I find some fault in the
> memcheck tests (which is fairly unlikely).
>
> [1] org.debug.internal.ui.sourcelookup.SourceLookupFacility#lookup, line
> 254
> [2] ValgrindLaunchConfigurationDelegate#createMarkers, line 241
>
> On Mon, 2014-06-02 at 06:05 +0000, Marc-André Laperle wrote:
>> Hi Jeff,
>>
>> It looks like something did change between Luna RC1 and RC2, see:
>> https://git.eclipse.org/r/#/c/27647/
>> and
>> https://git.eclipse.org/r/#/c/27648/
>>
>> (Note: I had to disable some tests in LTTng because of failing downloads, hopefully they will be fixed soon)
>>
>> Marc-Andre
>> ________________________________________
>> From: linuxtools-dev-bounces@xxxxxxxxxxx [linuxtools-dev-bounces@xxxxxxxxxxx] on behalf of Marc-André Laperle [marc-andre.laperle@xxxxxxxxxxxx]
>> Sent: Friday, 30 May 2014 6:16 PM
>> To: Linux Tools developer discussions
>> Subject: Re: [linuxtools-dev] [Hudson] Hudson build became unstable: linuxtools-luna #9
>>
>> I can reproduce it locally with Luna and going back to Kepler SR2 does
>> seem to fix the errors...strange. I have one remaining error in
>> testSegfaultHandle but it looks like an environment setup problem.
>>
>> Marc-Andre
>>
>> On 14-05-30 06:02 PM, Jeff Johnston wrote:
>>> Just saw this myself on a gerrit run.  I think something may have changed
>>> in Luna because /basicTest/test.c is used in another test and shouldn't be
>>> referenced here unless perhaps the BasicMemcheckTest is still tearing down
>>> when this test is running and it gets confused.  I am going to try and reproduce
>>> with a local build.  There is also a surefire property Roland suggested; I can try and see if it
>>> works on Hudson (threadCount 1).
>>>
>>> -- Jeff J.
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev



Back to the top