Hello,
After some additional testing, checking my environment and inspecting pyuno/
source/loader/pyuno_loader.cxx, I want to amend the report, particularly about
7.0.4 which is not affected (kind of).
First, I wonder if someone reproduces this on 1:6.1.5-3+deb10u6 (if nobody
does, I may whip up a VM to exclude other factors next Sunday).
Indeed, however, on 1:7.0.4~rc2-1~bpo10+2 the issue is *NOT* reproducible (at
least with the given steps, see below), and was only happening entirely due to
a local misconfiguration, as I had a trailing colon inside PYTHONPATH. That
causes Python 3 to crash with that error. My deepest apologies for polluting
the report with the wrong information about 7.0.4.
However, I can still reproduce this on 6.1.5, and changing absolutely nothing
in the environment, including deletion of ~/.config/libreoffice does not seem
to stop it, and there is no PYTHONPATH set in any form. I also noticed that
pyuno/source/loader/pyuno_loader.cxx from the buster source does add exactly
such trailing colon (an issue that has been explicitly fixed in 7.0.4, so only
Buster is affected):
bufPYTHONPATH.append( systemPath );
bufPYTHONPATH.append( static_cast<sal_Unicode>(SAL_PATHSEPARATOR) );
I see the code for buster-backports (and presumably bullseye) has been
modified to not leave either trailing colons or colons surrounding an empty
string by adding three explicit checks (except for one case, which threw off
my testing):
if (!systemPath.isEmpty())
{
if (bAppendSep)
bufPYTHONPATH.append(static_cast<sal_Unicode>(SAL_PATHSEPARATOR));
bufPYTHONPATH.append(systemPath);
bAppendSep = true;
}
....
const char * oldEnv = getenv( "PYTHONPATH");
if( oldEnv )
{
if (bAppendSep)
bufPYTHONPATH.append( static_cast<sal_Unicode>(SAL_PATHSEPARATOR)
);
bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv),
osl_getThreadTextEncoding()) );
}
However, in spite of this fix, I was still able to reproduce a *similar*
(though significantly less impactful) issue on 7.0.4. Since the code checks if
PYTHONPATH is set (as opposed to empty), passing an empty PYTHONPATH causes
LibreOffice to crash in the same manner (while Python 3 itself does not).
With unset PYTHONPATH:
* 1:6.1.5-3+deb10u6 from Buster crashes
* 7.0.4 from Buster Backports and Bullseye DOES NOT crash
With *empty* PYTHONPATH both crash.
$ PYTHONPATH= localc ./test.csv # this triggers it on 7.0.4
$ localc ./test.csv # this triggers it on 6.1.5
Best wishes, and I again apologize for the missing report, and for reporting
an issue that is fixed (-ish) in bullseye and sid.
P.S. Yeah, LibreOffice doesn't touch encodings.py. The error is produced by
Python during initialisation as it tries to determine the locale encoding, so
it happens before any external Python code is executed, and only happens if
something injects the local directory or an empty string in PYTHONPATH.
On неделя, 7 март 2021 г. 22:14:02 EET Rene Engelhard wrote:
> tag 984703 + moreinfo
>
> tag 984703 + unreproducible
>
> thanks
>
>
> Hi,
>
> Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> > When opening any CSV file with LibreOffice Calc, Calc opens and executes
> > encodings.py from the current working directory.
>
> Demonstrably wrong, see below.
>
> > That presumably happens because
> >
> > Some file managers, including Krusader and mc, would launch localc in the
> > current directory, as would running it from the command line (such as
> > `localc file.csv'), thereby running encodings.py from the directory
> > containing the file.
> >
> > The issue is not present when LibreOffice is launched through the
> > application launcher, and the file is opened later through whatever
> > means (neither Open file, nor through a file manager or the command
> > line, since localc already operates in one's $HOME in that instance)
> > To reproduce the issue, one needs to:
> > 1. Close LibreOffice *completely*
> > 2. In an empty directory, create "encodings.py" which raises an exception
>
> Created a encodings.py which contains "foo", which surely is not valid
> python.
>
> > 3. In the same directory (for simplicity), create "file.csv" with some
> >
> > rows.
>
> Did.
>
> 1,2
>
> ö,ä
>
>
> (last line to be sure there is some encoding in there)
>
> > 4. Open "file.csv" with `localc ./file.csv' using the directory containing
> >
> > "encodings.py" (double clicking in krusader and mc leads to the same
> > result)
>
> Done that.
>
> > The result is that LibreOffice crashes with the Python exception raised
> > by the rogue encodings.py, and then exits with an error that reads:
> > Fatal Python error: initfsencoding: Unable to get the locale encoding
>
> Just works here. Opens the .csv as is.
>
> > The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
> > Buster Backports (1:7.0.4~rc2-1~bpo10+2).
>
> Tried with 7.0.4-3 on bullseye (which should be identical to the
> backport you use in this regard)
>
> > No extensions not installed
> > by apt are present on either machine (on the one with 6.1.5 I never
> > installed any, and on the 7.0.4 I'm trusting what the LO extension
> > manager is telling me, since I cannot recall for sure)
>
> Something else you did?
>
> > Here's the console chatter:
> >
> > # Test on the host with 1:7.0.4~rc2-1~bpo10+2 - hostname is censored
> > milko@host2 ~/Временна/LOSecurity $ cat > encodings.py
>
> Maybe it is because of the *dir* this is in? I am so sure not creating a
> cyrillic directory to check.
>
> But even in a ~/öäü I just created, no crash and just an open of the .csv
>
> > raise NotImplementedError("Darth Vader, Obi-Wan and Ahsoka walk into a
> > bar") milko@host2 ~/Временна/LOSecurity $ cat > test.csv
> > Column 1;Column 2;Column 3
> > текст;ຂໍ້ຄວາມ;text
> > milko@host2 ~/Временна/LOSecurity $ localc test.csv
> > Fatal Python error: initfsencoding: Unable to get the locale encoding
> >
> > Traceback (most recent call last):
> > File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in <module>
> >
> > NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> > Fatal Python error: initfsencoding: Unable to get the locale encoding
> >
> > Traceback (most recent call last):
> > File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in <module>
> >
> > NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> > milko@host2 ~/Временна/LOSecurity $ cat > test2.csv
> > Column 1;Column 2;Column 3
> > text1;text2;text3
> > milko@host2 ~/Временна/LOSecurity $ localc test2.csv
> > Fatal Python error: initfsencoding: Unable to get the locale encoding
> >
> > Traceback (most recent call last):
> > File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in <module>
> >
> > NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> > Application Error
> > milko@host2 ~/Временна/LOSecurity $
>
> Even this doesn't produce any error. (in my ~/aöü)
>
> >> Can yu pleas make this directly a public report in the Debian BTS?
>
> Are you serious? For something unreproducible? Or were you able to
> reproduce it?
>
>
> Regards,
>
>
> Rene
