Bugzilla – Full Text Bug Listing
| Summary: | Build emf-graphiti-nighly (sic) appears to be hung | ||
|---|---|---|---|
| Product: | Community | Reporter: | Steve Powell <zteve.powell> |
| Component: | CI-Jenkins | Assignee: | CI Admin Inbox <ci.admin-inbox> |
| Status: | CLOSED NOT_ECLIPSE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | d_a_carver, glyn.normington, michael.wenz, webmaster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Steve Powell
The name does appear to be out of date. -M. This job has been resubmitted and is stuck in the same place. Please investigate for there are other anomalies on the slave which might be being caused by the coverage plug-in in this job..... Incidentally -- the first job I reported as hung failed as follows: java.io.IOException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:173) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:452) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:494) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:222) at java.io.InputStreamReader.read(InputStreamReader.java:177) at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:2992) at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046) at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) at org.xmlpull.mxp1.MXParser.nextTag(MXParser.java:1078) at hudson.plugins.emma.EmmaBuildAction.loadRatios(EmmaBuildAction.java:260) at hudson.plugins.emma.EmmaBuildAction.load(EmmaBuildAction.java:233) at hudson.plugins.emma.EmmaPublisher.perform(EmmaPublisher.java:126) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:550) at hudson.model.Build$RunnerImpl.post2(Build.java:152) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528) at hudson.model.Run.run(Run.java:1267) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122) and this implies it was hung in a hudson step that might have involved the main server or the slave as a whole. I had added Emma code coverage instrumentation paths for our plugins under test and though that caused the hanging. So I removed that stuff again and retriggered the build but as Steve already noticed the build hung again (I cancelled it by now). Any ideas why this hangs? Could it be an issue that we trigger to separate Emma test runs via Buckminster? That worked-out in the first place... -Michael (In reply to comment #0) > The Console log shows it took 10 minutes to build successfully, and now is > trying to produce coverage (emma) information. Has been for about an hour. > Incidentally, is this job mis-named? Yes, at least I think that I requested a job with "nightly" in the name; don't know where the error was, but this is definatly a typo. Can this still be changed? -Michael I've corrected the name to emf-graphiti-nightly. -M. (In reply to comment #6) > I've corrected the name to emf-graphiti-nightly. > -M. Great! Thanks for that. But that raised another issue: I'm no longer allowed to configure or trigger the job in Hudson. Could anyone give me permission for the new job again? (Username mwenz). Thanks, Michael (In reply to comment #7) > (In reply to comment #6) > > I've corrected the name to emf-graphiti-nightly. > > -M. > > Great! Thanks for that. > But that raised another issue: I'm no longer allowed to configure or trigger > the job in Hudson. Could anyone give me permission for the new job again? > (Username mwenz). > > Thanks, > Michael This should be fixed. ...meaning I added you as the admin, Michael. OK So the name's right. It appears not to have executed correctly after build 41, which ran the Emma plugin fine. Did you find out why the emma pplug-in blew up? Also, why did the build that had the emma plugin-explosion, report a SUCCESSful build? Surely, if a plug-in fails spectacularly then the build result should reflect that somehow? (In reply to comment #10) > OK So the name's right. It appears not to have executed correctly after build > 41, which ran the Emma plugin fine. Did you find out why the emma pplug-in > blew up? > Also, why did the build that had the emma plugin-explosion, report a SUCCESSful > build? Surely, if a plug-in fails spectacularly then the build result should > reflect that somehow? Not really. What I did was removing the Emma instrumentation paths definitions. Now it reports over our plugins under test and the test plugins again. To eliminate the test plugins from the coverage list I added the instrumentation paths like this using Emma tooling in the IDE: <listAttribute key="com.mountainminds.eclemma.core.INSTRUMENTATION_PATHS"> <listEntry value="/org.eclipse.graphiti/bin"/> </listAttribute> Why that change blew Emma I can't tell. After reverting the inserting above the build terminated successfully again. Also I can only speculate on why the build showed green although it hung: results were there, Build Successful message was written to the log, the coverage reports extisted, so from the build perspective everything looked fine. Only the Emma call did not return... - Michael Now that our Graphiti build has returned to normal again, I added the Emma result collection at the end again. It somehow works now although I use the same configuration as before. Strange, but I close this issue as resolved. -Michael (In reply to comment #12) > Now that our Graphiti build has returned to normal again, I added the Emma > result collection at the end again. It somehow works now although I use the > same configuration as before. Strange, but I close this issue as resolved. > > -Michael Michael. Can you tie this job to the master. There appears to be issues with the EMMA plugin for Hudson and running on a remote system. Periodically it'll get a Remote Connection Pipe exception, and when that happens, it hoses up Build2. We see this pretty consistently. > Michael. Can you tie this job to the master. There appears to be issues with
> the EMMA plugin for Hudson and running on a remote system. Periodically it'll
> get a Remote Connection Pipe exception, and when that happens, it hoses up
> Build2.
> We see this pretty consistently.
Dave, thanks for the hint. I did as you suggested.
-Michael
Done. |