View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0037884||Lazarus||Debugger||public||2020-10-07 22:27||2020-10-09 17:20|
|Reporter||nanobit||Assigned To||Martin Friebe|
|Fixed in Version||2.2|
|Summary||0037884: win32: Debugger run has ascii path limit?|
|Description||win32, 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.
|Tags||No tags attached.|
|Fixed in Revision||63978|
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
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:
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
Please test with r63978
Partially merged to fixes2.0 in r63979
Please specify when a debug issue is filed against fpdebug, thanks.
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.
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"
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?
||Great, it works now with stdcall.|
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"
|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|