Recent

Author Topic: problem executting tprocess with fpdebug  (Read 2650 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Re: problem executting tprocess with fpdebug
« Reply #15 on: February 27, 2021, 08:14:04 pm »
Ok, so I build a 32bit IDE for testing.

If the 32bit debuggee attempts to launch a 64bit app, I do get the error.
If I change to poDebugOnlyThisProcess => I no longer get the error.

I was not able to reproduce any other cases.

I will test poDebugOnlyThisProcess for a while, and change FpDebug accordingly at some time (not sure if it will hit the next release).


One more note, I have not tested this in relation to any debugger, but remember having had issues (not related to the IDE nor any debugger)
If notepad++ was "run as admin" and is running, then if you try to open another file in notepad++ (and that starts as normal user) there will be an error.


Out of interest...
As for works in gdb. Can you verify it is a 32bit gdb? There are after all 64bit versions of gdb too....
Though gdb may well set up things differently, but I am not going to dive into gdb sources at this time...


The easiest way for you to use fpdebug and (hopefully) not have the troubles is to instal Lazarus 64bit. And a cross compiler.

You can still develop your own apps as 32 bit apps. (You just need to change the target settings in project options).

But with the 64bit IDE comes 64bit fpdebug, and in my tests, with that there were no permission issues.

calebs

  • Full Member
  • ***
  • Posts: 147
Re: problem executting tprocess with fpdebug
« Reply #16 on: February 28, 2021, 03:57:32 pm »
Hello and thanks for taking the time to test all these.
I've had mixed experiencies with lazarus 64 bits, i develop much for low end machines and always work in 32 bits, even in linux with (the little) distros in 32bits... i've had a traumatical experience switching to 64bits and some currency functions that don't work aynmore so i stay away as long as i can from 64 bits lazarus because i have to modify a lot of the set of programs. I will take a closer look to the compiler target settings .
All the executables that i call in tprocess are 32 bits, i think. I have one that is an compiled python script that i have my doubts and i'll double check if it is 64 bit or 32.
Can you tell me how to change poDebugOnlyThisProcess ? i've changed the code in components\fpdebug\fpdbgwinclasses.pas and recompiled all lazarus but it keeps giving error 50.
Thx!

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Re: problem executting tprocess with fpdebug
« Reply #17 on: February 28, 2021, 04:22:33 pm »
Can you tell me how to change poDebugOnlyThisProcess ? i've changed the code in components\fpdebug\fpdbgwinclasses.pas and recompiled all lazarus but it keeps giving error 50.

That is exactly what I did. This is the only occurrence of poDebugProcess. And that I changed. Rebuild and done.

And searching gdb sources shows they use that flag too. Under some condition they use both together? But not sure when.
They also use CreateNewProcessGroup.

I have only searched the keywords in gdb, I have not studied the code around them.



If you cross compile to 32 bit, then you should get the exact same results, as if you compile in a 32 bit IDE. Its just the IDE that differs.

At least if you download the cross compiler add on from the lazarus download. => Because the lazarus-2.0.12-fpc-3.2.0-cross-i386-win32-win64.exe is really a native 32 bit fpc in disguise. It has just been renamed to be found as cross compiler.

But you can even go one step further. Install (or keep installed) the 32 bit compiler. Tools > Option: point to the 32 bit compiler (no cross compiling).
Your 64 bit IDE will compile all apps to 32 bit (you do NOT even have to change the targed in Project-Options, you keep it empty/default).
Only to rebuild the IDE, you need to then change back to the 64 bit fpc.
And of course any package in the IDE will be 64 bit, but in your app that package will be 32 bit. So that only matters if you write your own packages for the IDE.

Not saying I want to force you to a 64bit IDE. I would be happy to fix that do whatever extend is possible.
But currently I am not sure where to look....



On my tests, when the 64 bit app failed to launch, there was no event that Windows sent to FpDebug. So there was no answer from fpdebug that could have affected it.
It was simply that a debugger was attached in WOW64 mode. (32 bit on 64 bit OS)
You can add
  -dDebuglnWinDebugEvents
and run the ide with
  --debug-log=c:\file.log
it and I can see if I can spot something.

(If it compiles also uncomment all calls to "//DumpEvent" in fpdbgwinclasses.pas . BUt only if it compiles)


You can try to start without debugger, and attach (before the external process is launched). Just to see if it makes any diff....
But even if...


Again: You checked your gdb (with witch you said it worked) is actually 32 bit ?
While debugging, in the taskmanager it has the "(32bit)" suffix?


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Re: problem executting tprocess with fpdebug
« Reply #18 on: March 02, 2021, 02:05:23 am »
I don't know if will make a diff, but have you tried to specify both: poDebugProcess and poDebugOnlyThisProcess?

https://docs.microsoft.com/en-us/windows/win32/procthread/process-creation-flags
Quote
DEBUG_PROCESS.
If this flag is combined with DEBUG_ONLY_THIS_PROCESS,

It seems each one on its own can be given, but also both together.

calebs

  • Full Member
  • ***
  • Posts: 147
Re: problem executting tprocess with fpdebug
« Reply #19 on: March 02, 2021, 11:02:06 pm »
Hello all.
After research a little find that the compiled python script was 64 bits (reading it with an hex editor and microsoft pe guides) so i proceed to delete lazarus x86 and install lazarus x64 with the addon to compile in 32bits.
Have to modify the programs (i still have some bugs for sure, i assume a lot for rounding with decimal types) and after hit my head in the wall several times with random hangs in debugging with fpdebug and gdb, i found that i had to remove all the precompiled units (ppu's and alike) and it finally worked out without the 50 errror message when i call the other executables with tprocess.
I guess the problem was indeed calling a 64 bit executable within a 32bit ide debugger.
I don't know if it fail also if i call a 32bit program in a 64bit ide but i guess soon i will find out.
I'll take a note of your suggestions to modify fpdebug source if that error appear.
it will be a fix for this? i mean in a future version of lazarus would this work?
Thanks for the support.

ASBzone

  • Hero Member
  • *****
  • Posts: 616
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: problem executting tprocess with fpdebug
« Reply #20 on: March 03, 2021, 12:53:03 am »
it will be a fix for this? i mean in a future version of lazarus would this work?
Thanks for the support.

Thanks for following up here.

If what you are asking is:  "In the future, will a 32-bit process ever be allowed to call a 64-bit one" then the answer is "No, not directly."  This is not a Lazarus or FPC issue...
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.0.13 r64843 / FPC v3.2.1-r49055 (via FpcUpDeluxe) -- Windows 64-bit install w/Win32 and Linux/Arm cross-compiles
Primary System: Windows 10 Pro x64, Version 2009 (Build 19042)
Other Systems: Windows 10 Pro x64, Version 2009 (Build 19042) or greater

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Re: problem executting tprocess with fpdebug
« Reply #21 on: March 03, 2021, 01:11:16 am »
The issue is about the DebugThisProcessOnly flag. And yes I have plans to add that.

A 32 bit IDE can always only debug 32bit processes. (or must use an external 64bit debugger).

But that 32bit debuggee can start 64bit processes. That is, if the debugger has declared that it does not need/want to know about them. In my tests that flag has worked. So it will at least fix some of the issues reported here.

 

TinyPortal © 2005-2018