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-boun...@eclipse.org [linuxtools-dev-boun...@eclipse.org] > on behalf of Marc-André Laperle [marc-andre.lape...@ericsson.com] > 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
