View Issue Details

IDProjectCategoryView StatusLast Update
0037349LazarusDebuggerpublic2020-07-15 20:33
ReporterIgor Kokarev Assigned ToMartin Friebe  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2.0.10 
Summary0037349: Corrupt non-Latin environment-variables in Windows
DescriptionLazarus 2.0.10 + FPC 3.2.0 (x86-64) returns corrupt non-Latin environment-variables when I use ExpandEnvironmentStringsW() under default GDB debugger.

When I run directly the EXE file everything is OK.

My app reads a path to App Data and Documents folders. And if my Windows profile name contain Russian symbols ("Игорь") returned path is wrong for any system variable.
Steps To ReproduceRun the attached test project and see the text output.
Additional InformationThis problem didn't appear in Lazarus 2.0.6 + FPC 3.0.4 (x86-64).

Conversation: https://forum.lazarus.freepascal.org/index.php?topic=50572.msg369542
Tagsgdb
Fixed in Revision
LazTarget-
WidgetsetWin32/Win64
Attached Files

Relationships

related to 0036193 new win32 error with TOpenDialog.Execute 

Activities

Igor Kokarev

2020-07-14 19:19

reporter  

EnvBug.lpi (1,610 bytes)   
<?xml version="1.0" encoding="UTF-8"?>
<CONFIG>
  <ProjectOptions>
    <Version Value="11"/>
    <PathDelim Value="\"/>
    <General>
      <Flags>
        <MainUnitHasCreateFormStatements Value="False"/>
        <MainUnitHasTitleStatement Value="False"/>
        <MainUnitHasScaledStatement Value="False"/>
      </Flags>
      <SessionStorage Value="InProjectDir"/>
      <MainUnit Value="0"/>
      <Title Value="EnvBug"/>
      <UseAppBundle Value="False"/>
      <ResourceType Value="res"/>
    </General>
    <BuildModes Count="1">
      <Item1 Name="Default" Default="True"/>
    </BuildModes>
    <PublishOptions>
      <Version Value="2"/>
    </PublishOptions>
    <RunParams>
      <FormatVersion Value="2"/>
      <Modes Count="1">
        <Mode0 Name="default"/>
      </Modes>
    </RunParams>
    <Units Count="1">
      <Unit0>
        <Filename Value="EnvBug.lpr"/>
        <IsPartOfProject Value="True"/>
      </Unit0>
    </Units>
  </ProjectOptions>
  <CompilerOptions>
    <Version Value="11"/>
    <PathDelim Value="\"/>
    <Target>
      <Filename Value="EnvBug"/>
    </Target>
    <SearchPaths>
      <IncludeFiles Value="$(ProjOutDir)"/>
      <UnitOutputDirectory Value="lib\$(TargetCPU)-$(TargetOS)"/>
    </SearchPaths>
  </CompilerOptions>
  <Debugging>
    <Exceptions Count="3">
      <Item1>
        <Name Value="EAbort"/>
      </Item1>
      <Item2>
        <Name Value="ECodetoolError"/>
      </Item2>
      <Item3>
        <Name Value="EFOpenError"/>
      </Item3>
    </Exceptions>
  </Debugging>
</CONFIG>
EnvBug.lpi (1,610 bytes)   
EnvBug.lpr (723 bytes)   
{$APPTYPE CONSOLE}
program EnvBug;

function ExpandEnvironmentStringsW(lpSrc: PWideChar; lpDst: PWideChar;
  nSize: Cardinal): Cardinal; stdcall; external 'kernel32.dll' name 'ExpandEnvironmentStringsW';

function GetEnv(const Name: WideString): WideString;
var
  len  : Cardinal;
begin
  len:=ExpandEnvironmentStringsW( PWideChar(Name), nil, 0);
  if len>0 then begin
    SetLength( Result, len-1 );
    ExpandEnvironmentStringsW( PWideChar(Name), PWideChar(Result), len );
  end else Result:='';
end;

procedure Test(const Name : WideString);
begin
  WriteLn( 'EvnVar '+Name,' = ', GetEnv(Name) );
end;

begin
  Test('%LOCALAPPDATA%'); WriteLn;
  Write('Press ENTER to Exit'); ReadLn;
end.

EnvBug.lpr (723 bytes)   

Dmitry Boyarintsev

2020-07-14 23:01

developer   ~0124019

the issue seems to be related to 0036193, as both issues only experience the problem with the debugger.
Running without a debugger works just fine.

It might be there's a double issue
1) Lazarus passes information to Gdb in UTF8 encoded manner (while Ggb expects in ANSI? or Unicode?)
2) Gdb itself passes the information to the process in Ansi format?!

https://osdn.net/projects/mingw/lists/archive/users/2020-May/000502.html

Martin Friebe

2020-07-14 23:45

manager   ~0124021

The issue is probably caused by some build setting of gdb.
Our old version 7.3.5 appears to accept the input as it is.

It is possible that other gdb versions accepts system locale 8bit encoding... Not sure.

I don't think its actually something in the gdb version. But something about how gdb was build. But I have no info on that.

Martin Friebe

2020-07-15 20:33

manager   ~0124061

Reverted to gdb 7.3.5

Currently it is not clear how to build/obtain any newer gdb that supports unicode/utf8 for the environment.

Issue History

Date Modified Username Field Change
2020-07-14 19:19 Igor Kokarev New Issue
2020-07-14 19:19 Igor Kokarev Status new => assigned
2020-07-14 19:19 Igor Kokarev Assigned To => Martin Friebe
2020-07-14 19:19 Igor Kokarev File Added: EnvBug.lpi
2020-07-14 19:19 Igor Kokarev File Added: EnvBug.lpr
2020-07-14 19:20 Igor Kokarev Tag Attached: gdb
2020-07-14 22:58 Dmitry Boyarintsev Relationship added related to 0036193
2020-07-14 23:01 Dmitry Boyarintsev Note Added: 0124019
2020-07-14 23:45 Martin Friebe Note Added: 0124021
2020-07-15 20:33 Martin Friebe Status assigned => resolved
2020-07-15 20:33 Martin Friebe Resolution open => fixed
2020-07-15 20:33 Martin Friebe LazTarget => -
2020-07-15 20:33 Martin Friebe Widgetset Win32/Win64 => Win32/Win64
2020-07-15 20:33 Martin Friebe Note Added: 0124061