Hi Max, on another Ubuntu 14.10 machine, I have no issue as well. I'm starting to suspect an ubuntu upgrade effect on one of the system libs or the kernel. Would you have the time to see where one of those tests fail? Any one would probably tell me something. Thierry Le 07/03/2015 18:07, Max Leske a écrit :
On 06 Mar 2015, at 17:21, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-03-06 16:17 GMT+01:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 06 Mar 2015, at 16:08, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-03-06 15:43 GMT+01:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 06 Mar 2015, at 15:35, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-03-06 15:21 GMT+01:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 06 Mar 2015, at 14:56, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Ok. It's not an image problem. It seems to be a vm problem or an ubuntu problem.
(vm and vmLatest from get.pharo.org <http://get.pharo.org/> have that, the vm in the pharo launcher seems to work fine, and I haven't seen any problem with Pharo3 ? Ubuntu 14.10 64bits).
Ok, so we need to find the VM version that breaks OSProcessâ¦
I tried to rebuilt a vm from the git for pharo-vm, and it failed at the end of the process... lots of incorrect function redefinitions in cogit.c, if it says anything.
Yes, I know that. Itâs a problem with gcc. To fix it and get a working VM you can use the following:
/* pre-empty some preprocessor variables used in srv/vm/cogit.h, cointer.h, etc */ # define NoDbgRegParms # define NeverInline
In which header do you add that?
src/vm/cogit.h src/vm/cointerp.h
and src/vm/gcc3x-cointerp.c
Thanks, it worked. For the compilation, I mean. (the two .h happily contain code to define those two macros ??)
Ok, conclusion with a brand new VM: stuck at the very first test. The worst result of all :(
Thierry
I ran your tests a couple of times and didnât see any hangs or crashes (although most of the tests failed). This is on OSX 10.10.2.
output:
'Running tests in 1 Packages' MCGitFileTreeIssue139Test>>#testWrite [FAIL] MCGitFileTreeIssue139Test>>#testLoad [FAIL] MCGitFileTreeIssue139Test>>#testWriteNRead [FAIL] MCGitFileTreeIssue139Test>>#testRepository [FAIL] MCGitFileTreeIssue146Test>>#testWrite [FAIL] MCGitFileTreeIssue146Test>>#testWriteNRead [FAIL] MCGitFileTreeIssue147Test>>#testWriteNRead [FAIL] MCGitFileTreeIssue26Test>>#testWriteNRead2 [FAIL] MCGitFileTreeIssue26Test>>#testWrite [FAIL] MCGitFileTreeIssue26Test>>#testLoad [FAIL] MCGitFileTreeIssue26Test>>#testWriteNRead [FAIL] MCGitFileTreeIssue33Test>>#testWrite [FAIL] MCGitFileTreeIssue33Test>>#testLoad [FAIL] MCGitFileTreeIssue33Test>>#testWriteNRead [FAIL] MCGitFileTreeIssue33Test>>#testRepository [FAIL] MCGitFileTreeIssue69Test>>#testLoad [FAIL] MCGitFileTreeIssue72Test>>#testLoad [FAIL] MCGitFileTreeIssue72Test>>#testWriteNRead [FAIL] MCGitFileTreeLoaderTest>>#testBaseLoadRepository [FAIL] MCGitFileTreeLoaderTest>>#testCypressCuisLoad [FAIL] MCGitFileTreeLoaderTest>>#testIssue74 [FAIL] MCGitFileTreeLoaderTest>>#testTargetLoad [FAIL] MCGitFileTreeLoaderTest>>#testTargetLoadRepository [FAIL] MCGitFileTreeLoaderTest>>#testBaseLoad [FAIL] MCGitFileTreeLoaderTraitsTest>>#testLoad [FAIL] MCGitFileTreeTests>>#testStoreReadGitFileTree [31/31] Finished running 31 Tests