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

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.



Back to the top