Incorrect Process startup

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Incorrect Process startup

Steve Gatenby
Intermittantly (but consistantly), my app will run the wrong process
using either TAsyncProcess or RunCommand.

I understand it will be my bug, just looking for a clue :)

The 'Run' function is within a fpc library.

A loop calls the 'Run' function each second to run a system process (eg
ls or wmctrl etc) - have tried multiple processes, all do the same.

Symptoms are:

run wmctrl (or other) from the TProcess / RunCommand code
the TProcess instance returns the PID for the new process
read the relevant file under /proc/PID/status - it will intermittently
show the new process is actually a copy of the caller app.
(meaning: the orig app is called Test1, I try to run wmctrl, I end up
with 2 copies of Test1 running)

I have found through experimenting:

a pause of 100ms after running the process will fix 80% of cases.

for the other failures, I kill the newly created process, and try again
(this usually works)

As I said, just looking for ideas (and any such are much appreciated)

i7 8G ram 1T ssd - development only, no heavy background processes

Linux Lubuntu x86 32bit
Lazarus 1.7 r53034:53273M FPC 3.0.0 i386-linux-gtk 2

Thanks - SteveG
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Incorrect Process startup

Ewald-2
On 06/11/16 23:50, Steve Gatenby wrote:
> run wmctrl (or other) from the TProcess / RunCommand code
> the TProcess instance returns the PID for the new process
> read the relevant file under /proc/PID/status - it will intermittently
> show the new process is actually a copy of the caller app.
> (meaning: the orig app is called Test1, I try to run wmctrl, I end up
> with 2 copies of Test1 running)

Actually, this is quite exactly what I would expect here. Spawning a new
process on unix is actually a two step thingie:
        - First fork(), which duplicates the current process
        - The child then exec()'s, replacing its current process image
          with a new one (which would be the target executable in your
          case)

It is important to note that a lot of the parent process is preserved by
the child process. On such example are file descriptors, which are not
closed automatically for you. It is actually via this mechanism that
pipes to and from child processes can be established with relative ease.

More on this subject can be found at
        https://en.wikipedia.org/wiki/Fork%E2%80%93exec
        https://linux.die.net/man/2/clone
        https://linux.die.net/man/2/fork
        https://linux.die.net/man/3/exec

> I have found through experimenting:
>
> a pause of 100ms after running the process will fix 80% of cases.

Probably because the child has exec'ed by this time, if I had to guess.


--
Ewald
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Incorrect Process startup

Steve Gatenby
Thanks Ewald - will follow this up - much appreciated

On 08/11/16 07:40, Ewald wrote:

> On 06/11/16 23:50, Steve Gatenby wrote:
>> run wmctrl (or other) from the TProcess / RunCommand code
>> the TProcess instance returns the PID for the new process
>> read the relevant file under /proc/PID/status - it will intermittently
>> show the new process is actually a copy of the caller app.
>> (meaning: the orig app is called Test1, I try to run wmctrl, I end up
>> with 2 copies of Test1 running)
>
> Actually, this is quite exactly what I would expect here. Spawning a new
> process on unix is actually a two step thingie:
> - First fork(), which duplicates the current process
> - The child then exec()'s, replacing its current process image
>           with a new one (which would be the target executable in your
>           case)
>
> It is important to note that a lot of the parent process is preserved by
> the child process. On such example are file descriptors, which are not
> closed automatically for you. It is actually via this mechanism that
> pipes to and from child processes can be established with relative ease.
>
> More on this subject can be found at
> https://en.wikipedia.org/wiki/Fork%E2%80%93exec
> https://linux.die.net/man/2/clone
> https://linux.die.net/man/2/fork
> https://linux.die.net/man/3/exec
>
>> I have found through experimenting:
>>
>> a pause of 100ms after running the process will fix 80% of cases.
>
> Probably because the child has exec'ed by this time, if I had to guess.
>
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal