Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2016-11

Incorrect Process startup

3 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

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

Ewald
to Steve Gatenby
Steve Gatenby wrote 6 lines
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
Steve Gatenby
to Ewald

Thanks Ewald - will follow this up - much appreciated

Ewald wrote 33 lines
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.