SUnit improvements need review and feedback

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: SUnit improvements need review and feedback

Mariano Martinez Peck


On Mon, Sep 5, 2016 at 3:18 PM, Guille Polito <[hidden email]> wrote:
Hola,

for the record, I'm using OSSubprocess in several projects and it's pretty robust.


Good to hear that. 

 
The problems I had were because either:

- I was using it wrongly. e.g., I was deadlocking my process due to a process that was writing a lot to stdout. I fixed this after I read the entire documentation. I think that there should be a better warning at the beginning of the docs because all the starting examples do not use polling, and then this may create problems (because people read the documentation until they found what they needed, they will not read the entire thing ^^)


Indeed. But at the same time it's not that frequent to write that much into the stdout. 
 

- Or there was a library that was creating some noise with it. I remember at some point Seamless and OSSubprocess together were a crash factory. So I'm restarting now again with those two.

The thing is that it is really frustrating to have crashes all day long with something that should not crash :( It's not that I'm messing with the VM, or that I do not know what I am doing...


Exactly.  That's why I really want to fix that (even if this is not OSSubprocess fault). And I was unable so far :(   

 

-------- Original Message --------
Guille, 

Just for the record, there has been some crashes in Pharo using OSSubprocess, but I (we) were never able to reproduce nor found the cause, and even less a fix :(
So....any help in this direction is really appreciated as I want OSSubprocess to be robust. 

Cheers, 

On Mon, Sep 5, 2016 at 2:53 PM, Guillermo Polito <[hidden email]> wrote:
I mean crash.

Somehow my image's processes were killed and I only had the UI process: no delay process, no finalization, no idle process. Then, when the VM tries to suspend the current process and change to a second one, it finds none and it just quits.

So it's not a VM problem I think but mostly something in the image.

And in any case, now that I'm with a colder head (because I was mad after losing a couple of hours of work this afternoon :)) ):

 - first, I could not load OSSubprocess in latest pharo. I saw there were two test watcher processes and *killed* them.
 - then, I could load OSSubprocess, but it started crashing the image when running the tests from nautilus.
 - I tested with complex and simple OSSubprocess calls and I got always the same result
 - I even removed the child watcher process to see if that was the problem, but still crashing.

In any case, I'm not sure that this is because of this addition, it's just a hunch for the moment.


On Mon, Sep 5, 2016 at 7:47 PM, stepharo <[hidden email]> wrote:

ARgh, since this got integrated I keep crashing images...


do you mean real crash or DNU.
Because indeed I got some crashes too.







--




--
Reply | Threaded
Open this post in threaded view
|

Re: SUnit improvements need review and feedback

Denis Kudriashov
In reply to this post by Guillermo Polito

2016-09-05 18:23 GMT+02:00 Guillermo Polito <[hidden email]>:
ARgh, since this got integrated I keep crashing images...

I'm just executing some OSSubprocess like this:

process := OSSUnixSubprocess new
command: 'ls';
redirectStdout;
runAndWaitOnExitDo: [ :command :outString | ^ outString ].

and my image crashes with a:

(scheduler could not find a runnable process)

So this is messing up badly the scheduler. We have to fix this :/

To disable this changes just replace runCaseManaged with runCase in any senders.
It will approve is it related or not.

But if crash happens not during tests then it should not be related to this changes.
Reply | Threaded
Open this post in threaded view
|

Re: SUnit improvements need review and feedback

Denis Kudriashov
And fix for Guille case is inbox 19073. (details are inside)

2016-09-05 23:30 GMT+02:00 Denis Kudriashov <[hidden email]>:

2016-09-05 18:23 GMT+02:00 Guillermo Polito <[hidden email]>:
ARgh, since this got integrated I keep crashing images...

I'm just executing some OSSubprocess like this:

process := OSSUnixSubprocess new
command: 'ls';
redirectStdout;
runAndWaitOnExitDo: [ :command :outString | ^ outString ].

and my image crashes with a:

(scheduler could not find a runnable process)

So this is messing up badly the scheduler. We have to fix this :/

To disable this changes just replace runCaseManaged with runCase in any senders.
It will approve is it related or not.

But if crash happens not during tests then it should not be related to this changes.

Reply | Threaded
Open this post in threaded view
|

Re: SUnit improvements need review and feedback

stepharo

Tx denis.

I wonder what is the reason of the crashes I experienced.



Le 9/9/16 à 18:01, Denis Kudriashov a écrit :
And fix for Guille case is inbox 19073. (details are inside)

2016-09-05 23:30 GMT+02:00 Denis Kudriashov <[hidden email]>:

2016-09-05 18:23 GMT+02:00 Guillermo Polito <[hidden email]>:
ARgh, since this got integrated I keep crashing images...

I'm just executing some OSSubprocess like this:

process := OSSUnixSubprocess new
command: 'ls';
redirectStdout;
runAndWaitOnExitDo: [ :command :outString | ^ outString ].

and my image crashes with a:

(scheduler could not find a runnable process)

So this is messing up badly the scheduler. We have to fix this :/

To disable this changes just replace runCaseManaged with runCase in any senders.
It will approve is it related or not.

But if crash happens not during tests then it should not be related to this changes.


Reply | Threaded
Open this post in threaded view
|

Re: SUnit improvements need review and feedback

Denis Kudriashov

2016-09-09 18:09 GMT+02:00 stepharo <[hidden email]>:

Tx denis.

I wonder what is the reason of the crashes I experienced.


I don't know. Here is details on covered issue:

TestExecutionEnvironment introduces problem when image is saved inside test process (which is case for Guille code which fork image inside test). 
And problem is that snapshot restarts all low level processes like IdlProcess, eventLoop and others (which are spawned in startup list). And when it happens inside test process all child processes are intercepted and terminated when test completes which means killing all system processes on test completes
To fix it image snapshot should be always performed under default execution environment. (There is already another case like this: opening debugger to debug test. Debugger spawns new UI process and it should not be under test environment).

12