FpDebug problem

[440bx]

Hello,

When debugging using FpDebug, using the trunk version of FPC and Lazarus, the writeln(s) in the attached project are not output and eventually subsequent writeln(s) cause a runerror(101) to occur. 

The writeln(s) appear without problem when the project is debugged using GDB.

Also attached is a screenshot of the Lazarus and FPC versions.  O/S is Win 7, 64bit, SP1.

Comments welcome.

NOTE: I do not know if the problem also occurs in a different versions of Lazarus/FPC because the project requires FPC trunk to compile.

[Martin_fr]

While I am looking, have you tried "run without debug"?

[Martin_fr]

I just rebuild my IDE with FPC 1546c4a7947afcb45783b1251b01fd31016ef84d

When I run the project under FpDebug the "test" is printed as it should. (Then it hits the breakpoint, and exits)

I am on Win10 / 64 bits.

[Martin_fr]

FpDebug does not really do anything about the StdOut, or writeln.

It use TProcess from FPC (and TProcess changed in FPC trunk), to start the process, and that tell Windows which handles the new process should have.

[marcov]

Note that were updates in the last two days. If your trunk is even of yesterday morning, please retest.

[440bx]

I rebooted the machine and used FPCUPDELUXE to install a fresh copy of FPC and Lazarus trunk.

I got exactly the same behavior as before.  Specifically, when using FpDebug, for some reason the writeln(s) don't appear.  Changing the debugger to GDB, the writeln(s) appear (no other changes whatsoever.)

I cannot imagine why using FpDebug would cause writeln to stop working. I cannot imagine what in my installation could cause that either. (VM freshly rebooted and both FPC and Lazarus freshly installed without any custom configuration of any kind - not even colors or font - as "out of the box" as it gets.)

Attached are screenshots of what I get (same as before but, these screenshots have a smidgen more info.)  The GDB screenshot is taken of a run immediately after the FpDebug one, IOW, back to back runs.

[marcov]

Ok, thanks for trying, I just saw there was still movement there (even commits today) because the FPC testsuite also has problems with the new modifications, so work is still being done.

[440bx]

Ok, thanks for trying, I just saw there was still movement there (even commits today) because the FPC testsuite also has problems with the new modifications, so work is still being done.

Thanks, good to know.  I'll try again tomorrow, maybe later commits will solve the problem.

[Martin_fr]

1) What happen when "run without debug"?

2) Try compiling Lazarus with -WC => so lazarus has a console. Then while running your app, watch the Lazarus console too.

[Martin_fr]

I cannot imagine why using FpDebug would cause writeln to stop working.

FpDebug and "run without debug" use TProcess. Gdb does not (obviously).

TProcess (like - I guess - gdb) then calls WinApi, and when doing that specifies if the new process should get new handles, inherited handles, some other handles....
Something there might go wrong.

I did some (limited) tests on the new TProcess (but pre-release / not the latest), with Win XP ... 11. But the amount of options that can be combined are "endless" (technically not endless). And then it could also depend on the flags that fpc was build with, e.g. -gt -gttt ... would change behaviour if something wasn't initialized.

What is however strange is that - If I understand right - it is just the one app. Since the fpc part is about how winapi is called, it should be all apps or none.


Btw, you don't use thread, and write from different threads? (just on an off chance).

[marcov]

I don't think it is up to compiler details and paremeters, it is simply messing with std pipes.

[440bx]

FpDebug and "run without debug" use TProcess. Gdb does not (obviously).

That's right, now I remember you wanted me to test that.  Using FpDebug and "run without debug", no writeln(s) and the app crashes with a memory access violation.  It's sort of nice that the behavior is identical if the debugger is set to gdb and still "run without debug".

What is however strange is that - If I understand right - it is just the one app. Since the fpc part is about how winapi is called, it should be all apps or none.

I just tried it with another app (hadn't tried that before) and the result is the same, with FpDebug, no writeln output, with gdb, writeln works as expected.  See screenshots.

Btw, you don't use thread, and write from different threads? (just on an off chance).

Neither app is mine, IOW, I didn't write either of them (the first one is Jde.  I believe the first app is not multi-threaded and, I am sure the second one isn't.

I don't think it is up to compiler details and paremeters, it is simply messing with std pipes.

I think you're right.  Something seems to go wrong with the input/output handles/pipes when using FpDebug.  The second app failed with an "invalid handle" on the readln.

At this point, I am inclined to believe the problem is FPC stdin/out related.  I'll wait till tomorrow for further testing.


ETA:

added missing/forgotten attachments.

[marcov]

I think you're right.  Something seems to go wrong with the input/output handles/pipes when using FpDebug.  The second app failed with an "invalid handle" on the readln.

At this point, I am inclined to believe the problem is FPC stdin/out related.  I'll wait till tomorrow for further testing.

The TProcess modifications are relating to adding additional in application piping options, this is a major chance and bound to upset things. Please give Michael some time to fix the exceptions.

FYI: the said testsuite tried to redirect standard pascal file descriptors (input,output,error) with new ones and called windows specific functions on them.

[Martin_fr]

That's right, now I remember you wanted me to test that.  Using FpDebug and "run without debug", no writeln(s) and the app crashes with a memory access violation.  It's sort of nice that the behavior is identical if the debugger is set to gdb and still "run without debug".

"Run without debug" does not depend on the debugger, it always goes straight to TProcess.

At this point, I am inclined to believe the problem is FPC stdin/out related.  I'll wait till tomorrow for further testing.

Actually, since it is "run without debug" too, we can safely say: something with TProcess.

Does your fpc/rtl has debug info?

If yes, step into it, and right before the call to

Code: Pascal  [Select][+][-]

1.       If Not CreateProcessW (PWName,PWCommandLine,@FProcessAttributes,@FThreadAttributes,

Make snapshots of all the structures. Especially "FStartupInfo".

[440bx]

Does your fpc/rtl has debug info?

No, unfortunately, it does not.  That said, I see there is a "ppcx64.lpi", would using that project be sufficient to create an FPC with debug info ? 

Also, I see there is a ppcx64.exe in the bootstrap directory that does have debug info.  Would it be sufficient to simply replace the one found in fpc\bin\x86_64-win64 with that one ?

Additionally, the rtl .o and .ppu files do seem to include debug information (from visual inspection with a hex editor.) and system.o is roughly 1.5MB which feels too large to not have debug info.

I guess stepping is the "ultimate" test.  I'll give it a shot and report back.

ETA:

I just remembered that I had another set of somewhat recent Lazarus and FPC installations, using those installations the combination FpDebug/Writeln works fine.

Attached is a screenshot that shows the FPC/Lazarus version (where everything works fine.)