Unhandled win32 exception in P_Referenced_Decl [on some windows systems]

[pjljvandelaar]

Dear LibAdaLang developers,

The Dependency Graph Extractor has been moved to alire. We practice what we preach so we want to determine our own dependency graph. Libadalang is one of our dependencies. We observed that libadalang chrashed while analysing itself (C:\path\to\Dependency_Graph_Extractor-Ada\alire\cache\dependencies\libadalang_22.0.0_5f365aa4\src\libadalang-common.adb)

To reproduce this issue

1. Install alire and git.
2. Open alr powershell window
3. go to C:\path\to
4. git clone https://github.com/TNO/Dependency_Graph_Extractor-Ada.git
5. go to C:\path\to\Dependency_Graph_Extractor-Ada
6. git checkout libadalang_issue
7. alr build
8. alr run --args="-o dependency_graph_extractor.graphml -p C:\path\to\Dependency_Graph_Extractor-Ada dependency_graph_extractor.gpr"

This provides the following output: log.txt before the program stops: Debugging yields not much more info:

Looking at the log, we can clearly see that we are inside the function Get_Referenced_Decl.

 function Get_Referenced_Decl (Name : LAL.Name'Class) return LAL.Basic_Decl
   is
   begin
      Ada.Text_IO.Put_Line ("Get_Referenced_Decl");
      declare
         Referenced_Decl : constant LAL.Basic_Decl := Name.P_Referenced_Decl;
      begin
         Ada.Text_IO.Put_Line ("After P_Referenced_Decl");
         if Referenced_Decl.Is_Null then
            return Referenced_Decl;
         end if;

         --  In the case of a subprogram library unit use the specification and
         --  not the body when (a) the specification exists and (b) Name does
         --  not occur in the same unit as the body.
         if Is_Subp_Body_Unit_With_Spec (Referenced_Decl)
           and then Name.Unit.Root /= Referenced_Decl.Unit.Root
         then
            return Referenced_Decl.P_Previous_Part_For_Decl;
         else
            return Referenced_Decl;
         end if;
      end;
   end Get_Referenced_Decl;

yet haven't passed the line Ada.Text_IO.Put_Line ("After P_Referenced_Decl");. So the error must be triggered by the declaration Referenced_Decl : constant LAL.Basic_Decl := Name.P_Referenced_Decl;

However, we noticed that the problem does not occur on all windows systems on which we tested this behaviour!

Failing Windows system

About windows

Passing Windows system

About windows

Alire

About alire [installed via https://github.com/alire-project/alire/releases/download/v1.1.2/alr-1.1.2-installer-x86_64-windows.exe]

PS C:\path\to> alr version
Alr version: 1.1.2
Alire Library version: 1.1.2
alr status is (valid) (0 releases indexed) (loaded in 0.892s)
config folder is C:\Users\laarpjljvd\.config\alire
source folder is C:\Users\laarpjljvd\.config\alire\alire
interaction flags are: force:FALSE not-interactive:FALSE
alr root is empty
alr root detection has settled on path: C:\path\to\Dependency_Graph_Extractor-Ada
alr is finding 1 GPR project files
alr session state is [OUTSIDE]
alr compiled on [2022-01-27 13:44:56] with GNAT version [Community 2021 (20210519-103)]
platform fingerprint: Windows Bits_64 Msys2
platform properties: MSYS2 WINDOWS NATIVE USER BITS_64
community index required branch: stable-1.1

On failing machine

PS C:\path\to> alr toolchain
CRATE       VERSION STATUS    NOTES
gprbuild    22.0.1  Default
gnat_native 11.2.3  Available
gnat_native 11.2.4  Default

On passing machine

PS C:\path\to> alr toolchain
Nothing installed in configuration prefix C:\Users\nx011987\.config\alire

(Twice option 2 was selected).

Git

About git (on failing machine)

PS C:\path\to> git version
git version 2.33.1.windows.1

About git (on passing machine)

PS C:\path\to> git version
git version 2.35.1.windows.2

Hope that you can reproduce and make libadalang even better!

Greetings, Pierre

[pjljvandelaar]

The difference in behaviour might be related to a time out: we got

-- C:\path\to\Dependency_Graph_Extractor-Ada\alire\cache\dependencies\libadalang_22.0.0_5f365aa4\src\libadalang-common.adb --
Encountered Libadalang problem: logic resolution timed out
Id[569:33-569:42]: Text_Type

In the same file on exactly the same start position, so the time-out might hide the bug.

Can I as a user increase the time-out of libadalang? If so, how?

[raph-amiard]

Hi Pierre,

This looks like a quite hard to reproduce issue on our side, could you try to gather more information, by running this under gdb and seeing what exception exactly is being triggered ? TIA

[pjljvandelaar]

Hi Raphael,

Using a debugger was already a challenge: see https://gt3-prod-1.adacore.com/#/tickets/V420-006

But at least, I was able to get the following details about the exception:

Unhandled exception at 0x00007FFE78F84F69 (KernelBase.dll) in dependency_graph_extractor.exe: 0x20474343 (parameters: 0x0000016B402168A0).

Module Information: Version : 10.0.19041.1645 (WinBuild.160101.0800) orginal location: C:\Windows\System32\KernelBase.dll

Greetings, Pierre

[raph-amiard]

Ok that's not going to help tremendously :) One thing that you should investigate is memory consumption and whether you have enough memory available on this machine, since you only have 7gb available apparently, and if you're analysing a big closure this could be the culprit

[pjljvandelaar]

Memory usage is around 2 GB, so fortunately not near the available 7 GB.

[pjljvandelaar]

On the passing PC, I run the complete analysis. It succeeded, had no memory problems.

Analysis made two passes over the code. In both passes, only one time out issue is reported. The location is

-- C:\path\to\Dependency_Graph_Extractor-Ada\alire\cache\dependencies\libadalang_22.0.0_5f365aa4\src\libadalang-common.adb --
Encountered Libadalang problem: logic resolution timed out
Id[569:33-569:42]: Text_Type

For more details, see 2022-04-20-dependency_graph_extractor_output.txt