On 2013-10-30, at 16:04, Marcus Denker <marcus.denker@inria.fr> wrote:
On 30 Oct 2013, at 15:09, Camillo Bruni <camillobruni@gmail.com> 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/buildTi...
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?