As I wrote in my initial request I'm aware of the virtual memory thingy... (I even quoted that) The thing is that the same cvs command runs fine via shell on the same machine that continuum runs on. So I'm pretty sure that this is not [2] a memory issue on the cvs server. About 40 people are using the cvs server and memory never was a problem.
Continuum itself runs on a dedicated machine with 3GB RAM and an intel xeon 2GHz multicore cpu, this is rather oversized than insufficient hardware. Is it possible that the local JVM is out of memory? Although, wouldn't I got an OutOfMemory Exception if this was the case? Are you aware of situations when continuum's process needs a lot of memory? Is it possible to write the output of the cvs command to the continuum logs? -----Ursprüngliche Nachricht----- Von: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Gesendet: Montag, 12. November 2007 15:38 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: CVS checkout fails: "Terminated with fatal signal 11" After a quick search on Google [1], it seems you're not alone with this cvs error. But it's sure it isn't a Continuum error but a cvs issue, maybe a memory issue on the cvs server [2] [1] http://www.google.fr/search?q=Terminated+with+fatal+signal+11 [2] http://osdir.com/ml/version-control.cvs.bugs/2002-04/msg00298.html Emmanuel [EMAIL PROTECTED] a écrit : > Oh sorry, I think I missunderstood you. Thought you asked how often it > is used to run ;-) One checkout takes about 3 minutes. > > -----Ursprüngliche Nachricht----- > Von: Emmanuel Venisse [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 12. November 2007 13:28 > An: [EMAIL PROTECTED] > Betreff: Re: AW: CVS checkout fails: "Terminated with fatal signal 11" > > How many minutes are used to do a clean checkout? > > Emmanuel > > [EMAIL PROTECTED] a écrit : >> Can you give me a hint what to do to fix this problem? >> Or do you need more information? >> >> -----Ursprüngliche Nachricht----- >> Von: Renz, Manuel >> Gesendet: Donnerstag, 8. November 2007 12:59 >> An: [EMAIL PROTECTED] >> Betreff: AW: CVS checkout fails: "Terminated with fatal signal 11" >> >> It is planned to do a clean checkout once a day >> >> -----Ursprüngliche Nachricht----- >> Von: Emmanuel Venisse [mailto:[EMAIL PROTECTED] >> Gesendet: Mittwoch, 7. November 2007 20:19 >> An: [EMAIL PROTECTED] >> Betreff: Re: CVS checkout fails: "Terminated with fatal signal 11" >> >> It seems a kill was sent to the cvs client. >> >> How many time is used to do a checkout? >> >> Emmanuel >> >> [EMAIL PROTECTED] a écrit : >>> >>> Hi togehter, >>> I'm using continuum 1.1 beta 3 at the moment. I have set up 2 >>> Projects which work just fine. >>> >>> Now I'm in the process of setting up my third project, which is >>> quite large (clean checked out working copy round about ~260MB ), >>> with which I have massive problems. >>> >>> >>> Here is a short snippet from the logs: >>> >>> [SocketListener0-1] INFO FreemarkerManager - Instantiating >>> Freemarker ConfigManager!, >>> com.opensymphony.webwork.views.freemarker.FreemarkerManager >>> [SocketListener0-0] INFO Continuum:default - Enqueuing 'My-App' >>> (Build definition id=6). >>> [pool-1-thread-1] INFO BuildController:default - Initializing >>> build [pool-1-thread-1] INFO BuildController:default - Starting >>> build of My-App [pool-1-thread-1] INFO BuildController:default - >>> Updating working dir [pool-1-thread-1] INFO BuildController:default >>> - Performing action check-working-directory [pool-1-thread-1] INFO >>> BuildController:default - Performing action checkout-project >>> [pool-1-thread-1] INFO ContinuumScm:default - Checking out project: >>> 'My-App', id: '63' to 'D:\buildserver\data\working\63'. >>> [pool-1-thread-1] INFO ScmManager:default - Executing: cmd.exe /X >>> /C '"cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/CVS -q checkout -d 63 >>> my-app"' >>> [pool-1-thread-1] INFO ScmManager:default - Working directory: >>> D:\buildserver\data\working >>> ... >>> [pool-1-thread-1] WARN ContinuumScm:default - Error while checking >>> out the code for project: 'My-App', id: '63' to >>> 'D:\buildserver\data\working\63'. >>> [pool-1-thread-1] WARN ContinuumScm:default - Command output: >>> Terminated with fatal signal 11 >>> [pool-1-thread-1] WARN ContinuumScm:default - Provider message: The >>> cvs command failed. >>> [pool-1-thread-1] INFO BuildController:default - Merging SCM >>> results [pool-1-thread-1] INFO BuildController:default - Error >>> updating from SCM, not building [pool-1-thread-1] INFO >>> BuildController:default - Initializing build [pool-1-thread-1] INFO >>> BuildController:default - Starting build of parent >>> [pool-1-thread-1] INFO BuildController:default - Updating working >>> dir [pool-1-thread-1] INFO BuildController:default - Performing >>> action check-working-directory [pool-1-thread-1] INFO >>> BuildController:default - Performing action >>> update-working-directory-from-scm >>> >>> >>> In the build logs via the web UI I get just following information >>> and nothing more: >>> >>> Provider message: The cvs command failed. >>> Command output: >>> >>> -------------------------------------------------------------------- >>> - >>> - >>> -- >>> ------- >>> Terminated with fatal signal 11 >>> >>> -------------------------------------------------------------------- >>> - >>> - >>> -- >>> ------- >>> >>> When I run "cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/CVS -q checkout -d >>> 63 my-app" manually on the commandline it works like a charme, so I >>> think the problem is on some layer between cvs.exe and continuum... >>> >>> I googled and found this: >>> ------------------------------------------------ >>> Terminated with fatal signal 11 >>> >>> This message usually indicates that CVS (the server, if you're using >>> client/server mode) has run out of (virtual) memory. Although CVS >>> tries to catch the error and issue a more meaningful message, there >>> are many circumstances where that is not possible. If you appear to >>> have lots of memory available to the system, the problem is most >>> likely that you're running into a system-wide limit on the amount of >>> memory a single process can use or a similar process-specific limit. >>> The mechanisms for displaying and setting such limits vary from >>> system to system, so you'll have to consult an expert for your >>> particular system if you don't know how to do that. >>> ------------------------------------------------ >>> >>> But since the command works if it is run outside of continuum I >>> think this is not a memory problem on the server. >>> >>> >>> Hopefully somebody can give me a hint... >>> >>> Greetings >>> Manuel Renz >>> -- >>> Notice: This transmittal and/or attachments may be privileged >>> orconfidential. If you are not the intended recipient, you are >>> hereby notified that you have received this transmittal in error; >>> any review, dissemination, or copying is strictly prohibited. If you >>> received this transmittal in error, please notify us immediately by >>> reply and immediately delete this message and all its attachments. Thank >>> you. >>> >>> >> >> > > >
