View Issue Details

IDProjectCategoryView StatusLast Update
0037884LazarusDebuggerpublic2020-10-09 17:20
Reporternanobit Assigned ToMartin Friebe  
Status resolvedResolutionfixed 
Product Version2.0.10 
Fixed in Version2.2 
Summary0037884: win32: Debugger run has ascii path limit?
Descriptionwin32, fpc3.2, lazarus 2.10
The debugger-run (F9) hangs if "target file name" (definable in project compiler options)
contains non-ascii ( > ordinal 127) characters. Have to terminate the frozen IDE to get out.
The same problem occurs also if the real project directory name contains non-ascii characters.
TagsNo tags attached.
Fixed in Revision63978
Attached Files


Martin Friebe

2020-10-08 02:02

manager   ~0126137

I am unable to reproduce.

"win32" => this is the 32 bit IDE with a 32 bit fpc?
I tried both 32 and 64 bit.

What is your locale, and what are some sample chars?

On an English system, putting ö and â into the path.
I also tried some Japanese char, but then it would not even compile.

Could you produce a logfile please?

4) (64bit only)
There is a known issue on 64bit with gdb 8.2 (probably not gdb specific, but rather a problem with the particular build of gdb)
It trashes all >127 chars in environment. (And possible in the filename too).
This is remedied, by switching back to GDB 7.3.5 for the next release.

If you are on 64 bit, please get gdb 7.3.5

Actually the 32 bit gdb have not yet been fully tested for those issues.
But at least some filenames appear to work / Not sure on environment


2020-10-08 09:06

reporter   ~0126139

Windows 10 Wow64, Lazarus 32 bit, FPC 32 bit

Yes, target filename (eg. pröject.exe) with 'ö'
($F6, even if part of locale page) shows the problem.

Problem happens only with:
"GNU debugger (with fpdebug)", "FP debug internal Dwarf-debugger",
(whereas "GNU debugger" works)

With Dwarf debug info (all versions).
All GDB versions (7.2, 7.7, 8.2)

"FP debug internal Dwarf-debugger" brings no message, just IDE hanging.
"GNU debugger (with fpdebug)" brings message which can be closed:

[Window Title]
The debugger experienced an unknown condition

Press "Ignore" to continue debugging. This may NOT be safe. Press "Abort" to stop the debugger.
Exception: Exception with message "Invalid file handle"
Context: TFpGDBMIDebuggerCommandStartDebugging. State: dsStop

  $00D0C1F3 Create, line 228 of fpimgreaderbase.pas
  $00D0C0DF Create, line 208 of fpimgreaderbase.pas
  $00D09265 Create, line 217 of fpdbgloader.pp
  $00ED4C66 LoadDwarf, line 757 of fpgdbmidebugger.pp
  $00ED4B32 DoExecute, line 719 of fpgdbmidebugger.pp
  $00812EBC Execute, line 12620 of gdbmidebugger.pp

[Abort] [Ignore]

Martin Friebe

2020-10-08 23:08

manager   ~0126157

Please test with r63978

Partially merged to fixes2.0 in r63979

Please specify when a debug issue is filed against fpdebug, thanks.


2020-10-09 12:55

reporter   ~0126175

Last edited: 2020-10-09 13:41

View 2 revisions

I installed Lazarus trunk version today, but could not test fpDebug based debuggers.
They cause the IDE to silently crash when I press F9, regardless of project.
The reason might be unrelated to this latest change.
But the simple "GNU debugger (gdb)" works.

And "Project options / debugger" does not keep fpdebug selected after dialog close,
is automatically set to "GNU gebugger (gdb)" later, which then works as replacement.

Martin Friebe

2020-10-09 15:27

manager   ~0126182

Please re-open if you comment.

Do you have more detail on the 2 issues?
I use fpdebug under trunk all the time. (Though I will re-test with 32bit IDE).

Do you get a stacktrace for the crash?

I also do not get the "Project options / debugger does not keep fpdebug"
Can you supply the lpi / lps for such a project?
1) After you set the project to fpdeubg, and saved the project)
2) After you re-opened and run the project (and it used gdb)

Please also supply your "environmentoptions.xml"

Martin Friebe

2020-10-09 16:19

manager   ~0126185

Actually the 32 bit crash (if it is 32bit) may have been related.

Since fpc did not have the API declaration, copying from another API call missed the stdcall. (and that currently goes unnoticed on 64bit / at least 3.0.4)

Please let me know, if that fixes it.


For the other issue, could you please open a new report?


2020-10-09 16:51

reporter   ~0126187

Great, it works now with stdcall.

Martin Friebe

2020-10-09 17:20

manager   ~0126188

I merged that to fixes too.

Fixes should be ok with umlauts etc.
But fixes may hang, if opening the file fails for other reasons.

Please open a new issue for the "does not keep setting"

Issue History

Date Modified Username Field Change
2020-10-07 22:27 nanobit New Issue
2020-10-07 22:27 nanobit Status new => assigned
2020-10-07 22:27 nanobit Assigned To => Martin Friebe
2020-10-08 02:02 Martin Friebe Status assigned => feedback
2020-10-08 02:02 Martin Friebe LazTarget => -
2020-10-08 02:02 Martin Friebe Note Added: 0126137
2020-10-08 09:06 nanobit Note Added: 0126139
2020-10-08 09:06 nanobit Status feedback => assigned
2020-10-08 23:08 Martin Friebe Status assigned => resolved
2020-10-08 23:08 Martin Friebe Resolution open => fixed
2020-10-08 23:08 Martin Friebe Fixed in Version => 2.2
2020-10-08 23:08 Martin Friebe Fixed in Revision => 63978
2020-10-08 23:08 Martin Friebe LazTarget - => 2.2
2020-10-08 23:08 Martin Friebe Widgetset Win32/Win64 => Win32/Win64
2020-10-08 23:08 Martin Friebe Note Added: 0126157
2020-10-09 12:55 nanobit Note Added: 0126175
2020-10-09 13:41 nanobit Note Edited: 0126175 View Revisions
2020-10-09 15:27 Martin Friebe Status resolved => feedback
2020-10-09 15:27 Martin Friebe Resolution fixed => open
2020-10-09 15:27 Martin Friebe Note Added: 0126182
2020-10-09 16:19 Martin Friebe Note Added: 0126185
2020-10-09 16:51 nanobit Note Added: 0126187
2020-10-09 16:51 nanobit Status feedback => assigned
2020-10-09 17:20 Martin Friebe Status assigned => resolved
2020-10-09 17:20 Martin Friebe Resolution open => fixed
2020-10-09 17:20 Martin Friebe Widgetset Win32/Win64 => Win32/Win64
2020-10-09 17:20 Martin Friebe Note Added: 0126188