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-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 _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev