Steps to reproduce:
What happens:
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$0000000000000000
$000000000087FD72
$000000000056E476
$00000000005F642E
$00000000005E36C9
$00000000005F8F2E
$0000000000478B4E
$000000000047A566
$00000000004309EB
$00000000004758F6
Exception at 0000000000000000: EAccessViolation:
Access violation.
Exception at 00000000004B2E36: EAccessViolation:
Access violation.
CudaText: 1.121.0
Widget sets: qt5, gtk2, gtk3
Wich SO? sorry.
Wich SO? sorry.
NixOS
no error here if I run it from Ubuntu terminal.... Can somebody repro this? on NixOS?
Dependencies versions:
$ cat pkgs/applications/editors/cudatext/deps.json | jq -r 'keys[] as $k | "\($k) \(.[$k] | .rev)"'
ATBinHex-Lazarus 2020.09.05
ATFlatControls 2020.11.02
ATSynEdit 6560bc35a2cf31399be8713ac189216afabf9f01
ATSynEdit_Cmp 2459ea2a2e50050f7e6ee59a17a52aae05ca4433
ATSynEdit_Ex 2020.10.04
CudaText-lexers 2020.08.10
EControl 2020.10.04
Emmet-Pascal 2020.09.05
EncConv 2020.06.15
Python-for-Lazarus 2020.10.23
bgrabitmap v11.3.1
That won't help me. I need some 'repro steps'. do you see the crash if you run it from IDE?
wait....
EControl 2020.10.04
it's too old!
ATSynEdit+ATFlatControls: try all last!
Updating deps did not help:
$ cat pkgs/applications/editors/cudatext/deps.json | jq -r 'keys[] as $k | "\($k) \(.[$k] | .rev)"'
ATBinHex-Lazarus 2020.09.05
ATFlatControls 2021.01.12
ATSynEdit 2021.01.12
ATSynEdit_Cmp 206b41b44e137b644b10bf1e04f942a6441a70d1
ATSynEdit_Ex 2020.10.04
CudaText-lexers 2020.08.10
EControl 2021.01.12
Emmet-Pascal 2020.09.05
EncConv 2020.06.15
Python-for-Lazarus 2021.01.08
bgrabitmap v11.3.1
By the way, build fails with latest ATSynEdit_Cmp 2020.10.11:
formmain.pas(7645) Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted
That's why I use rev 206b41b44e137b644b10bf1e04f942a6441a70d1.
ATSynEdit_Cmp - made the 'release' now, ok.
Could you see the crash in IDE? if yes pls show the 'call stack' window of IDE during crash?
No, not reproduced if I build in IDE or just out of nix store. But toolchain and dependencies are exact the same.
My IDE shows if I click [copy to clipboard] in the About dialog
Lazarus 2.1.0 r64335 FPC 3.2.1 x86_64-linux-gtk2
what is yours?
$ lazarus-ide -v
2.0.10 SVN Revision: 2.0.10-2
$ lazbuild -v
2.0.10
$ fpc
Free Pascal Compiler version 3.2.0 [2021/01/05] for x86_64
...
Looks like the problem is nix specific somehow, as far as when I build using lazbuild out of nix store, resulting cudatext doesn't crash on exit, but when I build nix package using lazbuild, resulting cudatext crashes on exit.
One more detail: there is no such problem with cudatext 1.118.2 and deps:
$ cat pkgs/applications/editors/cudatext/deps.json | jq -r 'keys[] as $k | "\($k) \(.[$k] | .rev)"'
ATBinHex-Lazarus 2020.09.05
ATFlatControls 2020.11.02
ATSynEdit 6560bc35a2cf31399be8713ac189216afabf9f01
ATSynEdit_Cmp 2459ea2a2e50050f7e6ee59a17a52aae05ca4433
ATSynEdit_Ex 2020.10.04
CudaText-lexers 2020.08.10
EControl 2020.10.04
Emmet-Pascal 2020.09.05
EncConv 2020.06.15
Python-for-Lazarus 2020.10.23
bgrabitmap v11.3.1
Sorry, i am puzzled now, how can it be 'Nix specific'...
Sorry, i am puzzled now, how can it be 'Nix specific'...
I take my words back, since 1.118.2 is OK, so something going wrong between 1.118.2 and 1.122.0.
I am puzzled.
I'll try to update versions of cuda+deps step by step to figure out what version caused the problem.
I've finally found the root cause: downgrading Python-for-Lazarus from 2021.01.08 to 2020.10.23 solves the problem (more exactly this commit caused crash).
So, here is a stable deps set for cudatext 1.122.0:
$ cat pkgs/applications/editors/cudatext/deps.json | jq -r 'keys[] as $k | "\($k) \(.[$k] | .rev)"'
ATBinHex-Lazarus 2020.09.05
ATFlatControls 2021.01.12
ATSynEdit 2021.01.12
ATSynEdit_Cmp 2021.01.12
ATSynEdit_Ex 2020.10.04
CudaText-lexers 2020.08.10
EControl 2021.01.12
Emmet-Pascal 2020.09.05
EncConv 2020.06.15
Python-for-Lazarus 2020.10.23
bgrabitmap v11.3.1
@pyscripter I don't have idea how this commit
https://github.com/Alexey-T/Python-for-Lazarus/commit/c4a0720a2b1b83d19cd50fe26a42efcf25f88d64
which is clone of yours, makes the program crash on "file / quit"...
@sikmir Maybe one of 'nearest' commits in Python-for-lazarus makes it? one of commits which adds python imported function or like this..
@sikmir Maybe one of 'nearest' commits in Python-for-lazarus makes it? one of commits which adds python imported function or like this..
At least what I see now, https://github.com/Alexey-T/Python-for-Lazarus/commit/8ebe14f1f6a3e21f2ef8bbaaee44f23e85bf07b8 (2020.10.23) is OK, but next commit https://github.com/Alexey-T/Python-for-Lazarus/commit/c4a0720a2b1b83d19cd50fe26a42efcf25f88d64 causes crash.
One more observation, in the first case I see the following in the CudaText console:
Python 3.8
Startup: 90ms, plugins: 0ms ()
But in the second case I see only:
Startup: 90ms, plugins: 0ms ()
And there is no warnings that python is not found.
@sikmir thanks. Let's see does your OS have python 3.10 lib? and/or 3.9 lib? the patch makes finding the 3.10, then 3.9, then 3.8.... until 3.6.
Let's see does your OS have python 3.10 lib? and/or 3.9 lib? the patch makes finding the 3.10, then 3.9, then 3.8.... until 3.6.
Before building CudaText, I patch this line:
https://github.com/Alexey-T/CudaText/blob/e343f848db61a0e70b98b00c0d70bb170dc119b9/app/proc_globdata.pas#L1005
with full path:
exit('/nix/store/yi9a1fafijn0nf5m8qkmnl955vi2mncm-python3-3.8.6/lib/libpython3.so');
So, only python 3.8 is available for CudaText.
But that patch also tries to find 3.10; 3.9. Does NixOS have them? somewhere in PATH?
But that patch also tries to find 3.10; 3.9. Does NixOS have them? somewhere in PATH?
No, that's NixOS specific that all dependencies pinned at build time, application can't find any other lib somewere else, other than exact one specified at build time.
found the reason! https://github.com/pyscripter/python4delphi/issues/274
@sikmir Pls test with updated Py4Lazarus pkg!
@Alexey-T Well, updated Py4Lazarus doesn't fix, but nevermind, as I figured out, replacing:
exit('/nix/store/yi9a1fafijn0nf5m8qkmnl955vi2mncm-python3-3.8.6/lib/libpython3.so');
with
exit('/nix/store/yi9a1fafijn0nf5m8qkmnl955vi2mncm-python3-3.8.6/lib/libpython3.8.so');
makes PythonVersionFromDLLName happy! Sure, both libpython3.so and libpython3.8.so are exist.
So, the actual problem is that PythonVersionFromDLLName fails in case LibName doesn't have minor version part. But original DetectPythonVersionFromLibName (up to 2020.10.23) was able to handle it without crashing somehow.
For string ...../libpython3.so my code cannot detect 3.8 . it detected 3.0! so it runs wrong 'parts'.
For string
...../libpython3.somy code cannot detect 3.8 . it detected 3.0! so it runs wrong 'parts'.
But with Cuda 1.118.2 (Python-for-Lazarus 2020.10.23), I see in console:
Python 3.8
Loaded session: "history session.json", 0ms, 0 file(s) + 1 modified
Startup: 100ms, plugins: 0ms ()
So, 3.8 properly detected I guess, in spite of ...../libpython3.so.
Yes.... so maybe 'old detection code' was error prone.. I dunno
We have solved this?
We have solved this?
Sure, thanks for assistance!