On 2013-10-30, at 16:04, Marcus Denker <[email protected]> wrote:
> > On 30 Oct 2013, at 15:09, Camillo Bruni <[email protected]> wrote: > >> Failing Tests >> ------------- >> Seems like our test splitup did not work properly: >> >> https://ci.inria.fr/pharo/job/Pharo-3.0/ >> >> The tests starting with A-L did not run since a while! >> > > But I always checked and even waited for them to finish.. to me it looked > that they where run each time > I did an update. > > I check the tests after every update. A-L have one failing tests, related to > Job (which started to fail recently), and that only on Linux. > Why jenkis shows no test runs I do not know. humm ok, that makes me even more suspicious :P, because there is not even a history right now :/. Well, let's wait until the CI infrastructure is back to normal. >> From what I get quite a bunch of tests are failing. >> >> >> Pending Processes + Default Username >> ------------------------------------ >> There is a strange amount of processes hanging around in the image. >> Plus there was a report that a default user name was set in the image (Not >> sure if that still persists, since I directly set mine with startup >> preferences). >> Was a new image version ben uploaded manually? >> > > I did a manual one recently (last week?) but I did not set any user name. > (I wanted to check if the processes are in the image that we download, they > are not). ok, so maybe re-uploading a new image will do the trick? >> Unstable Image + VM >> ------------------- >> Additionally since a while the image became much more unstable after running >> the tests >> twice (I know not a common case, but it should NEVER provoke a VM crash), >> see here: >> >> https://ci.inria.fr/pharo/view/3.0-Analysis/job/Pharo-3.0-Test-Twice/buildTimeTrend >> >> From what I get, ReleaseTest>>testObsoleteBehaviors provokes a VM crash. > > It was crashing the Opal Regression tests, too. Last wee I added a > #flushCache to the #fixObsoleteReferences > and that fixed it for the Opal Tests. Good. Do you think it would make sense to always call #flushCache if you manually trigger the GC?
signature.asc
Description: Message signed with OpenPGP using GPGMail
