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 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). Thierry 2015-03-06 14:10 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:

Hi Max,

I didn't have any problem until today, so I suspect it's a more recent change than 387. I'll bisect ;)

Thierry

2015-03-06 13:48 GMT+01:00 Max Leske <maxleske@gmail.com>:

...

Hi Thierry

Can you verify that the same doesn't happen before the integration? The first image with any change related to the Delays would probably be in 4.0 387.

Cheers, Max

...

On 06 Mar 2015, at 13:22, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi all,

does anybody knows if the recent delay change could have an impact on OSProcess?

I just rebuilt a Pharo4 image (40535) and I have random failures* when waiting for the termination of OSProcess commands

* i.e. they fail to terminate. Found stuck on Delay>>wait.

Thanks,

Thierry

2015-03-06 15:21 GMT+01:00 Max Leske <maxleske@gmail.com>:

On 06 Mar 2015, at 14:56, Thierry Goubier <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 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. Note. The pharo launcher vm and the get.pharo.org vm are very similar (5 days difference), but compiled on very different systems (gcc version and linux kernel version). Thierry

2015-03-06 15:43 GMT+01:00 Max Leske <maxleske@gmail.com>:

On 06 Mar 2015, at 15:35, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2015-03-06 15:21 GMT+01:00 Max Leske <maxleske@gmail.com>:

...

On 06 Mar 2015, at 14:56, Thierry Goubier <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 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?

Note. The pharo launcher vm and the get.pharo.org vm are very similar (5 days difference), but compiled on very different systems (gcc version and linux kernel version).

Interesting. Do you have a test case that I could try on my machine?

It's a bit a by hand process, but it should be scriptable :(

mkdir pharo cd pharo; wget -O- get.pharo.org/40+vmLatest | bash cd .. pharo/pharo pharo/Pharo.image --no-default-preferences eval --save Metacello new baseline: \'FileTree\'\; repository: \'github://dalehenrich/filetree:pharo4.0_dev/repository\'\; load: \'Git\' pharo/pharo pharo/Pharo.image --no-default-preferences eval --save Gofer new url: \'gitfiletree:// github.com/dalehenrich/filetree?branch=pharo4.0_dev\&dir=repository\'\; package: \'MonticelloFileTree-Tests\'\; package: \'MonticelloFileTree-GitTests\' pharo/pharo pharo/Pharo.image --no-default-preferences test "*GitTests" In my case, it gets stuck somewhere randomly in the process. It could even reach the end (I've seen it deadlock at the very last test :(). If, on the last line, I use the pharo-vm-nox of pharo-launcher, then it will run all tests. Thierry

...

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

...

...

Note. The pharo launcher vm and the get.pharo.org <http://get.pharo.org/> vm are very similar (5 days difference), but compiled on very different systems (gcc version and linux kernel version).

Interesting. Do you have a test case that I could try on my machine?

It's a bit a by hand process, but it should be scriptable :(

mkdir pharo cd pharo; wget -O- get.pharo.org/40+vmLatest <http://get.pharo.org/40+vmLatest> | bash cd .. pharo/pharo pharo/Pharo.image --no-default-preferences eval --save Metacello new baseline: \'FileTree\'\; repository: \'github://dalehenrich/filetree:pharo4.0_dev/repository\'\ <github://dalehenrich/filetree:pharo4.0_dev/repository/'/>; load: \'Git\' pharo/pharo pharo/Pharo.image --no-default-preferences eval --save Gofer new url: \'gitfiletree://github.com/dalehenrich/filetree?branch=pharo4.0_dev\&dir=repository\ <http://github.com/dalehenrich/filetree?branch=pharo4.0_dev\&dir=repository\>'\; package: \'MonticelloFileTree-Tests\'\; package: \'MonticelloFileTree-GitTests\' pharo/pharo pharo/Pharo.image --no-default-preferences test "*GitTests"

In my case, it gets stuck somewhere randomly in the process. It could even reach the end (I've seen it deadlock at the very last test :().

If, on the last line, I use the pharo-vm-nox of pharo-launcher, then it will run all tests.

I’ll give that a try later.

...

Thierry

On 06 Mar 2015, at 17:21, Thierry Goubier <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

On 07 Mar 2015, at 19:59, Thierry Goubier <thierry.goubier@gmail.com> wrote:

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.

ouch :)

Would you have the time to see where one of those tests fail? Any one would probably tell me something.

Sorry, I forgot. The problem seems to be that the issue tests are located in directories which do not contain a .git directory. Thus the git commands fail. Fuel file of the stack: https://www.dropbox.com/s/4dzst3cdgupcnr7/Debugger-Stack-MCFileTreeGitReposi... <https://www.dropbox.com/s/4dzst3cdgupcnr7/Debugger-Stack-MCFileTreeGitReposi...> Stack trace: MCFileTreeGitRepository class(Object)>>error: [ c := PipeableOSProcess command: self gitCommand , ' ' , aCommandString environment: nil workingDir: (MCFileTreeFileUtils current directoryPathString: aDirectory) input: nil output: nil error: nil errorPipelineStream: nil. r := c output. "Force the command to terminate." c succeeded ifFalse: [ | errorString | errorString := c errorUpToEndOfFile. errorString notEmpty ifTrue: [ self error: 'Git error: ' , errorString ]. r := '' ] ] in MCFileTreeGitRepository class>>runOSProcessGitCommand:in: in Block: [ ... BlockClosure>>ensure: MCFileTreeGitRepository class>>runOSProcessGitCommand:in: MCFileTreeGitRepository class>>runGitCommand:in: MCFileTreeGitRepository>>gitCommand:in: MCFileTreeGitRepository>>gitVersions MCFileTreeGitRepository>>loadAncestry [ :bar | anAncestry := self loadAncestry. 1 to: entries size do: [ :i | (entries at: i) in: [ :entry | | entryVersions v | entryVersions := OrderedCollection new. commitIDs := self gitVersionsForPackage: entry name. [ commitIDs atEnd ] whileFalse: [ | logSize commitID author position message dateAndTime | (commitIDs match: 'log size ') ifFalse: [ self error: 'Unable to find git data in input' ]. logSize := Integer readFrom: commitIDs. commitIDs next. position := commitIDs position. commitID := ByteArray readHexFrom: (commitIDs upTo: $|) trimBoth. author := (commitIDs upTo: $|) onlyLetters. dateAndTime := DateAndTime fromString: (commitIDs upTo: $|). message := (commitIDs next: logSize + 1 + position - commitIDs position) convertFromSystemString. entryVersions add: (GitFileTreePackageEntry on: entry name id: commitID author: author message: message timeStamp: dateAndTime) ]. v := 1. entryVersions size to: 1 by: -1 do: [ :j | (entryVersions at: j) buildInfoWith: entryVersions startingAt: j + 1 version: v ancestry: anAncestry. v := v + 1 ]. allNames addAll: entryVersions ]. bar value: i ] ] in MCFileTreeGitRepository>>loadAllFileNames in Block: [ :bar | ... BlockClosure>>cull: [ result := block cull: self ] in [ self prepareForRunning. [ result := block cull: self ] on: JobNotification do: [ :notification | notification handle: self ] ] in Job>>run in Block: [ result := block cull: self ] BlockClosure>>on:do: [ self prepareForRunning. [ result := block cull: self ] on: JobNotification do: [ :notification | notification handle: self ] ] in Job>>run in Block: [ ... BlockClosure>>ensure: Job>>run MorphicUIManager(UIManager)>>displayProgress:from:to:during: ByteString(String)>>displayProgressFrom:to:during: MCFileTreeGitRepository>>loadAllFileNames MCFileTreeGitRepository>>allFileNames MCFileTreeGitRepository>>readableFileNames MCFileTreeGitRepository(MCFileBasedRepository)>>allVersionNames [ self allVersionNames ] in MCFileTreeGitRepository(MCFileBasedRepository)>>goferReferences in Block: [ self allVersionNames ] BlockClosure>>on:do: MCFileTreeGitRepository(MCFileBasedRepository)>>goferReferences [ aRepository goferReferences asSortedCollection asArray ] in Gofer>>basicReferencesIn: in Block: [ aRepository goferReferences asSortedCollection a...etc... BlockClosure>>on:do: Gofer>>basicReferencesIn: [ self basicReferencesIn: aRepository ] in Gofer>>allResolvedIn: in Block: [ self basicReferencesIn: aRepository ] [ self at: key put: aBlock value ] in Dictionary>>at:ifAbsentPut: in Block: [ self at: key put: aBlock value ] Dictionary>>at:ifAbsent:

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