using pins with a path on arm64 causes infinite loop

[dalybrown]

I'm not sure if this has been mentioned in other issues. I'm using an arm64 linux container and I can never get pins to work properly.

As a basic example, I want to with a dependency in another folder.

[[depends-on]]
dependency = "*"

[[pins]]
dependency = { path = "path/to/dependency" }

This will cause alire to spin out of control. On a related note, I can't use the command alr with dependency --use /path/to/dependency to set this up because it will print an error:

error: Loading release from manifest: /workspaces/reproducer/alire/tmp/alr-kpcu.tmp:
error:    Failed to load /workspaces/reproducer/alire/tmp/alr-kpcu.tmp:
error:    invalid path name ""

I'm using this version of alire: alr 1.2.1.

I'm using this architecture: aarch64 GNU/Linux.

[mosteo]

Hi @dalybrown, thanks for the report. I guess you're building alr from sources?

Would you mind to try with the master branch to see if the problem persists? Otherwise, if you can point me to a similar containerized setup that would help me in reproducing it, that would speed up things.

[dalybrown]

Hey! No problem. I'll make a reproducer for you later today (or tomorrow...) and can provide an arm64 container for you that can reproduce it.

I was building it from sources until recently when the arm64 version of alire was available as a debian package: https://packages.debian.org/sid/arm64/alire/download. I use that now instead of building from sources. However, I can build the default branch and try this out.

[dalybrown]

Sorry - I've been away on and off the past couple of weeks so I haven't had time to make a reproducer for you.

I should mention that the alr pin <crate> --use=git@... command also fails on arm64 architecture. The same command works on amd64 (I tried both in the exact same project but different docker container platforms).

The output for the pin command I get when runnning in on arm64 is:

debug: 
malloc(): unsorted double linked list corrupted
Aborted

It seems to actually clone the repository fine ... so that part works at least.

If I manually update the .toml file to include the dependency and the pin to the URL, the same behaviour as a local folder occurs: infinite loop.

[dalybrown]

Here is a reproducer. You'll have to build the docker image yourself since it is too big to attach. You can run make docker-image and it will build the arm64 image for you (assuming you have docker installed).

You can run the image with the following then: docker run -it alire_pin_reproducer /bin/bash

Try to pin the second project in /dep. When that doesn't work, manually add the pin to the alire.toml file and try to update the project. The reproducer is located under /home/reproducer.

alr-pin-reproducer.tar.gz

[mosteo]

Thanks, @dalybrown, much appreciated.

[dalybrown]

I should note that using the latest commit on the main branch, I see a bit different behaviour now. The following is the output when I try to pin a local create using with --use=path/to/crate:

error: Loading release from manifest: XXX:alire/tmp/alr-emqg.tmp:
error:    Failed to load XXX/alire/tmp/alr-emqg.tmp:
error:    invalid path name ""

I see this information also when running with verbose logging:

stderr: ADA.IO_EXCEPTIONS.NAME_ERROR
stderr: invalid path name ""
stderr: raised ADA.IO_EXCEPTIONS.NAME_ERROR : invalid path name ""

If I manually edit .toml file to add the pin and update, I get the following:

stderr: CONSTRAINT_ERROR
stderr: alire-user_pins.adb:62 range check failed
stderr: raised CONSTRAINT_ERROR : alire-user_pins.adb:62 range check failed

[dalybrown]

I was able to fix the issue locally, but it doesn't seem like it is the root cause. During my debugging, I traced it to this line: https://github.com/alire-project/alire/blob/master/src/alire/alire-vfs.ads#L103. The expression function seems to cause an exception that I noted above. If I move the expression function to the body of the package it still causes the exception.

However, if I use a regular function, the issue goes away and I can pin! Weird! The following is what I changed it to:

   function To_Portable (Path : Relative_Path) return Portable_Path
   is
   begin
      case GNATCOLL.OS.Constants.OS is
         when MacOS | Unix =>
            return Portable_Path (Path);
         when Windows      =>
            return Portable_Path (Replace (Path, "\", "/"));
      end case;
   end To_Portable;

I'd have to read the reference manual in detail to understand what change this made and what was causing the exception before. This can't be the root cause of it since it doesn't make sense ... but it works! (for now...).

Do you think I should make a pull request to make that change for now or is someone more knowledgeable about this area able to properly debug it?

[mosteo]

It's not the first time I see bugs related to expression functions vs regular functions. If this fixes your issue, there's no problem in making that a regular function, and the PR is certainly welcome.