Sign in Join

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

Mailing lists / fpc-devel / 2015-03

Tprocess using pipes, handle = 0

9 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

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

Martin Frb

This is based on a report I got. I can not reproduce myself. (I bcc the reporter, and hope he will comment)

ON a 664 bit amd linux,
fpc_2.6.4-140420_amd64.deb (apparently the one from Lazarus sourceforge)

The problem started with an error launching the debugger.

Apparently the error occurs only, if the IDE is run without logging (console or file), suggesting a timing issue. But not sure about it. It also appears that the presence of the error relates to other errors before. (*.ico file not found, but looking further I can not see how this relates)

The IDE tries to run gdb (there is no variable here, at this time the to-be-debugged-app is NOT yet accessed, nor is its path passed.

TProcess.Execute
(in components\lazdebuggergdbmi\cmdlinedebugger.pp ) is executed.

After that

      Result := FDbgProcess.Running;

returns true (there is a check in the IDE code and it passes)

Then the IDE wants to read gdb output, and according to debugging FDbgProcess.Output.Handle
is zero.
The IDE then creates an error due to that.

Further debugging was done, and the value of
FDbgProcess.FOutputStream.FHandle
was inspected immediately after
TProcess.Execute

It was zero already.
It is my understanding (from browsing the code), that if TProcess.Execute is succesful, the handle will be set after it returns.

So if all reports I got are correct, then it looks like an issue in TProcess.Execute.

Any ideas?

Reply by email

Martin Frb
to Martin Frb
Martin Frb wrote 12 lines
Further debugging was done, and the value of FDbgProcess.FOutputStream.FHandle was inspected immediately after TProcess.Execute It was zero already. It is my understanding (from browsing the code), that if TProcess.Execute is succesful, the handle will be set after it returns. So if all reports I got are correct, then it looks like an issue in TProcess.Execute.

Just a quick question:

is 0 (zero) an invalid handle (on linux)?

Or could an Handle (active/all ok) be 0?

Reply by email

Marco van de Voort
to Martin Frb

In our previous episode, Martin Frb said:

Show quoted text 8 lines
> So if all reports I got are correct, then it looks like an issue in > TProcess.Execute. Just a quick question: is 0 (zero) an invalid handle (on linux)? Or could an Handle (active/all ok) be 0?

0 is standard input.

Reply by email

Martin Frb
to Marco van de Voort
Marco van de Voort wrote
> Or could an Handle (active/all ok) be 0? 0 is standard input.

Ah, except, if stdiin is closed, it can go to whatever handle is next....

And I have to go and fix some 10 year old code (that now started failing)

Reply by email

Martin Frb
to Martin Frb
Martin Frb wrote 6 lines
On 17/03/2015 21:00, Marco van de Voort wrote: >> Or could an Handle (active/all ok) be 0? > 0 is standard input. > Ah, except, if stdiin is closed, it can go to whatever handle is next....

Are there any values that are known to be ont a handle?

On windows codetools find InvalidHandleValue = -1
But on Linux I found nothing like this.

Given that fpselect is documented to have a bit-array of 256 bits, I would guess only 0 to 255 are valid? Though of course that may change...

What about -1 or negative in generic?

Reply by email

Michael Van Canneyt
to Martin Frb
Martin Frb wrote 17 lines
On 17/03/2015 21:04, Martin Frb wrote: > On 17/03/2015 21:00, Marco van de Voort wrote: >>> Or could an Handle (active/all ok) be 0? >> 0 is standard input. >> > > Ah, except, if stdiin is closed, it can go to whatever handle is next.... Are there any values that are known to be ont a handle? On windows codetools find InvalidHandleValue = -1 But on Linux I found nothing like this. Given that fpselect is documented to have a bit-array of 256 bits, I would guess only 0 to 255 are valid? Though of course that may change... What about -1 or negative in generic?

Negative is not a valid file handle.

Michael.

Reply by email

Marco van de Voort
to Martin Frb: Are there any values that are known to be ont a handle? On windows codetools find…

In our previous episode, Martin Frb said:

Show quoted text 8 lines
Are there any values that are known to be ont a handle? On windows codetools find InvalidHandleValue = -1 But on Linux I found nothing like this. Given that fpselect is documented to have a bit-array of 256 bits, I would guess only 0 to 255 are valid? Though of course that may change...

Where? If I look up in the help I only find
http://www.freepascal.org/docs-html/rtl/baseunix/tfdset.html

1024 seems to be a standard value for maxfd.

Reply by email

Martin Frb
to Marco van de Voort
Marco van de Voort wrote 14 lines
In our previous episode, Martin Frb said: > Are there any values that are known to be ont a handle? > > On windows codetools find InvalidHandleValue = -1 > But on Linux I found nothing like this. > > Given that fpselect is documented to have a bit-array of 256 bits, I > would guess only 0 to 255 are valid? Though of course that may change... Where? If I look up in the help I only find http://www.freepascal.org/docs-html/rtl/baseunix/tfdset.html 1024 seems to be a standard value for maxfd.

I googled fpselect, and got here:

http://www.freepascal.org/docs-html/rtl/baseunix/fpselect.html

2nd paragraph in description

readfds, writefds and exceptfds are pointers to arrays of 256 bits.

Reply by email