fix: update connect button styles to fix layout shift

Currently, the ConnectButton's height in the disconnected state is about 1px shorter than the connected state's height (which is always fixed at 40px). This PR slightly modifies the connect button's styles to match the 40px height and fix the layout shift.
Before
Connecting and disconnecting shifts the text below:

After
Set at 40px:

Nice catch! 🙏
This will need a changeset so it goes out in a release. If you run pnpm changeset and follow the prompts, this should go out as a patch release. You can look at previous PRs if you need a reference for what the generated file should look like.


Unable to access Magento_CatalogInventory resource during stock check API call

On the product page encountering issue with checking stock API call "Consumer is not authorized to access Magento_CatalogInventory::cataloginventory", I have created and activated integration key from Magento 2 with full access to site
Magento 2.3.3

Related to Magento itself specific, solved by disabling varnish temporarily


Remove rack

alt to #529
I can't find a need for the rack dependency

sorry about that. thought I had gone back to master before creating this branch...

no problem :) let's see what travis says

We need Rack for the test Rack app, but I'm not sure if we actually need it for anything else. I'm investigating now.

@davidbegin which test rack app?

other PR failed, I'll tweak that and push again.

@bblimke https://github.com/bblimke/webmock/blob/master/spec/support/my_rack_app.rb

I'm testing this out locally, push up my branch also https://travis-ci.org/bblimke/webmock/builds/85209158

ahh Rack::Lock

this needs to be a development dependency. I updated this accordingly. Test passed locally. (and this time I didn't have the other commit in there to fix)

cool - you've got covered. just close if you want.
thanks for all the help.

Thanks for reporting this fast, and finding a fix, I going to work on getting a new version out.


Is possible remove filetype:pdf and get only links?

Congratulations for your work! It is amazing.
I have one question about the pdf filetype. Is possible to add any tag 'filter_file_extensions' at run.js to get only links or a specific filetype?
I need to remove pdf files, but, if I scrap it, I think that is unnecessary for my context.
Could you help me, please?

Solved!
I just put: -filetype:pdf in keywords
Greats!


committee-account activities page white screen

Original issue #1999
Please investigate and report where the error comes from.

This issue is reproduced with 100% rate in the case when we open several browser tabs with any page. Its occurs during fetching in gatewayMethods.js .  It`s not reproduced with FireFox and looks like a Chrome feature https://www.chromestatus.com/feature/5527160148197376

The reason of white screen was missing notification component in bitshares-ui-style-guide. After deleting node modules and reinstalling the package problem gone

Was there any code change necessary now?
Or is the multiple tab reason above the only reason? Does it still reproduce after reinstalling with multiple tabs?

Was there any code change necessary now?
Or is the multiple tab reason above the only reason? Does it still reproduce after reinstalling with multiple tabs?

oh sorry, This comment is not for this issue


Provide the raw specifier for the module fallback service

Fixes: https://github.com/cloudflare/workerd/issues/2112

I took a stab at testing this using a local build from this PR and I can confirm that the raw parameter works as expected.
I modified @dario-piotrowicz's app to test this. You can see my changes here: https://github.com/dario-piotrowicz/miniflare-ModuleFallbackService-demo/compare/main...IgorMinar:miniflare-ModuleFallbackService-demo:workerd-pr-2131-test?expand=1
Overall, while I succeeded in getting the fallback service to work, I had to hack around a lot and I don't have confidence that this will fly in the real world, without further changes in workerd. Specifically workerd's inability to support bare specifiers and specifiers ending with / seems troublesome - see my TODO(discuss) comments in the PR above.
Btw I do find raw as the param name to be too ambiguous and as you can see in my code, I resorted to calling the value rawSpecifier in my code — we should consider renaming it.
Interestingly, I found that workerd resolved specifier is still useful to detect when a redirect is needed, which implies that we actually need both the workerd-resolved specifier as well as the raw specifier. This surprised me, but it's likely a good news for us as we don't need to deprecate and remove the original specifier.
Let's discuss this a bit before this change is merged.
side note: I had to employ 301 redirects to get everything to work, but I think that is expected, as this is exactly why the fallback service supports the redirects at all.

btw I can't give you review on the c++ code as I'm not familiar with the code base, so my approval is simply just stating that from the external point of view the code does what we asked for it to do. It would be good to have someone from the runtime team to confirm the correctness of the implementation.

@fhanau @dom96 @garrettgu10 ... would like to get this landed soon to unblock @IgorMinar's team. Can I ask one of y'all to do a quick review on this?


⚠ PrivateHD has degraded performance

In 84f5481, PrivateHD ($PHD) experienced degraded performance:

HTTP code: 200
Response time: 1497 ms

Resolved: PrivateHD performance has improved in da38bc4.


VA Profile - Remove list of returned values in PUT request

#704
These changes anticipate a change in the body of the POST requests we will receive from VA Profile and implement a corresponding change in the body of the PUT requests we will make back to them.  The changes also refactor the lambda handler by moving the PUT request to a standalone function that is easier to unit test.

I'm converting this PR to a draft pending clarification of the requirements.


Error with MOM5 with current main

The current GEOSgcm main (as of today) seems to have an issue running MOM5. But as near as I can tell nothing has fundamentally changed with MOM5! There were some changes to GEOSgcm_App from Ricardo, but I tested those in a MOM5 run yesterday and it seemed to work. I also did an xxdiff between a working run from last night to the current test and pretty much all the differences are in whitespace!
To wit as an example in this file (NOTE the SLURM file name will change everynight):
/discover/nobackup/mathomp4/SystemTests/runs/AGCM_MOM5/c90_MOM5_GOCART/CURRENT/run/1day/slurm-47377862.out

the error is:
 Integer*4 Resource Parameter: CICE_NDYN_DT:1
                                  Memuse(MB) at SEAICEMAPL_GenericInitialize=  3.498E+02  3.498E+02  3.318E+02  3.375E+02  0.000E+00
                                                           Mem/Swap Used (MB) at SEAICEMAPL_GenericInitialize=  1.548E+04  0.000E+00
                                                CommitLimit/Committed_AS (MB) at SEAICEMAPL_GenericInitialize=  1.801E+05  4.323E+04
NOTE from PE     0: diag_manager_mod::diag_manager_init: prepend_date only supported when diag_manager_init is called with time_init present.
MOMInitialize                                  877
MOMInitialize                                  877

Looking in GEOSgcm_GridComp:
! Check local sizes of two horizontal dimensions
!-----------------------------------------------

    call mom4_get_dimensions(isc, iec, jsc, jec, nk_out=LM)
    call MAPL_GridGet(GRID, localCellCountPerDim=counts, RC=status)
    VERIFY_(STATUS)

    IM=iec-isc+1
    JM=jec-jsc+1

    ASSERT_(counts(1)==IM)
    ASSERT_(counts(2)==JM)

the line in question (877) is:
    ASSERT_(counts(1)==IM)

This error did not happen in MAPL develop tests last night, so I can't blame MAPL.
I will probably be consulting @yvikhlya and @sanAkel about this.

Well, I ran MOM5 at NAS on this "day of no NCCS" and it's duplicable.
To try and debug, first, I added some prints in that chunk of code above:
    write(*,*) "counts(1): ", counts(1)
    write(*,*) "counts(2): ", counts(2)
    write(*,*) "iec: ", iec, "isc: ", isc
    write(*,*) "jec: ", iec, "jsc: ", isc
    write(*,*) "IM :", IM
    write(*,*) "JM :", JM

Here counts is from MAPL and iec, jec, etc. come from MOM5 (via FMS I guess?). In the good run (v10.19.4):
 counts(1):           10
 counts(2):           20
 iec:          290 isc:          281
 jec:          290 jsc:          281
 IM :          10
 JM :          20

and on a bad run (main):
 counts(1):           10
 counts(2):           20
 iec:            0 isc:            0
 jec:            0 jsc:            0
 IM :           1
 JM :           1

So for some reason, MOM/FMS is returning...no grid? Or something.
And again...we did not touch MOM5. Or FMS.
And Ricardo's App changes are pretty boring. I did a test where I made an experiment in main but used the GEOSgcm.x from v10.19.4 and that is happy, so I can't see there being an issue in the gcm_setup phase.

Looks like a problem with decomposition. isc, jsc, iec, jec are start and ens indexes of compute domain. IM, JM is size of the domain.

Looks like a problem with decomposition. isc, jsc, iec, jec are start and ens indexes of compute domain. IM, JM is size of the domain.

@yvikhlya I agree but...nothing changed. My hope was that input.nml or something that helps control MOM got screwed up, but nope. Exactly the same!
My current fear is that this is one of those "We changed the memory state and things are running differently" things. As in, we can add a print statement in MOM5 somewhere and all will work again!

@mathomp4
I can try look into it with you on Monday next week - in a debug build.

We will get back to this issue on a later date. @mathomp4 closing it for now, please feel free to reopen if needed. Thanks!

Seems like ocean_model_init did not run properly and grid dimensions which are returned by mom4_get_dimensions are junk. Now, why is that?

It may be easier or faster to know why using 1-deg resolution that @mathomp4 says has the same problem.

I already have 0.25 degree set up and interactive session, so I don't see a need to switch to 1 degree.

The last successful run with MOM5 I did was with v10.14.1 about 2 years ago. Something got broken since then.

@yvikhlya Not really. When this happened I was just confused. It just sort of "happened" one night and the only changes I could see were whitespace changes! It was like all of the sudden the system decided to do this.
I suppose one possible thought is to try a run with GNU? Maybe it will show a different error? I am not sure.

@mathomp4 Unrelated issue, but I can't push staff to github today. I have my ssh rsa key uploaded to github and i was always to push without password, but today it asks me a password and then says that I need access token. How do you use github these days?

@mathomp4 Do you have any suggestion how to debug this? I can't think of anything better that put printouts inside of ocean_model_init.

Well, 2 suggestions:

Use the debugger- the debug build worked for me a few months ago.
Again please use the 1-deg version. That will be easier to work with.

@mathomp4 There is something wrong here. The printout from MOM5 run:
NOTE from PE     0: callTree: ---> ocean_model_init(), ocean_model_MOM.F90

ocean_model_MOM.F90 is a part of MOM6, not MOM5. MOM5 should search for ocean_model_init() in the ocean_model.F90. There is a name collision here.

@mathomp4 There is something wrong here. A printout from MOM5 run:

NOTE from PE     0: callTree: ---> ocean_model_init(), ocean_model_MOM.F90

ocean_model_MOM.F90 is a part of MOM6, not MOM5. MOM5 should search for ocean_model_init() in the ocean_model.F90. There is a name collision here.
P.S. Just verified that it runs MOM_GEOS5PlugMod.F90 (MOM5), but ocean_model_init from MOM6, not from MOM5.

Hmm! Maybe that shared object lib/ DSO stuff hitting us again?

We might need to add back LD_PRELOAD?

@mathomp4 Could you remind me how to use LD_PRELOAD in csh? It works in bash for me:
$ LD_PRELOAD=/home/yvikhlia/aogcm/coupled/S2Sv4/update030622/GEOSgcm/install-Debug/lib/libmom.so ldd GEOSgcm.x | grep libmom
        /home/yvikhlia/aogcm/coupled/S2Sv4/update030622/GEOSgcm/install-Debug/lib/libmom.so (0x00002b81fdeef000)
        libmom6.so => /home/yvikhlia/aogcm/coupled/S2Sv4/update030622/GEOSgcm/install-Debug/lib/libmom6.so (0x00002b82129ee000)

But gives error in csh:
> LD_PRELOAD=/home/yvikhlia/aogcm/coupled/S2Sv4/update030622/GEOSgcm/install-Debug/lib/libmom.so ldd GEOSgcm.x | grep libmom
LD_PRELOAD=/home/yvikhlia/aogcm/coupled/S2Sv4/update030622/GEOSgcm/install-Debug/lib/libmom.so: Command not found.

> set LD_PRELOAD=/home/yvikhlia/aogcm/coupled/S2Sv4/update030622/GEOSgcm/install-Debug/lib/libmom.so ldd GEOSgcm.x | grep libmom
set: Variable name must contain alphanumeric characters.

@yvikhlya You have to use env:
env LD_PRELOAD=${GEOSDIR}/lib/libmom5.so ...

LD_PRELOAD works! MOM5 initialized correctly. If this is a solution we are going to use, we need to update gcm_run.j and submit a PR (I can do it).

Nice! I suppose a simple "If MOM5, add LD_PRELOAD" can work.

The model crashed in land component tough with error:
<CATCH_INTERNAL_RST is NOT consistent with VEGDYN Data>

Ouch. Yeah. That's when I start asking around!

I can confirm that works for both:

MOM5
MOM6


Sender facing: what happened to my data?

Problem Statement
As a sender, hey Reportstream, I gave you data. What happened to the data? How much of it got sent to public health authorities, HHS, anywhere else?
Note

This is a problem for all senders, regardless of api/csv/sftp connection type.
To start, Pipeline team will work on providing this information within ReportStream. See https://app.zenhub.com/workspaces/pipeline-6182b02547c1130010f459db/issues/cdcgov/prime-reportstream/4538
-Experience team will provide this info to end users.

Acceptance Criteria

Descriptive stats to show
[ ] denominator: Number of records submitted to Reportstream and intended for x public health authority
[ ] numerator: Number of records delivered to individual public health authorities
[ ] percent: numerator over denominator

Turned into an epic


Add hyperalignment functionality to nltools

I've been wanting to do this for awhile.  Maybe we can borrow ideas from hyper tools?

fixed in #204


Same message is being consumed by the multiple pods. (Consumer)

Questions?
*I am running my kafka-node application in 8 pods. It consumes from a topic(6 partitions) and does some processing. But I found out that each pod is consuming the same message. So the same message is being processed 8 times. I am using 'Consumer' of kafka-node. How to make the messages getting sent to only one pod?
Bug Report
Environment

Node version:
Kafka-node version: 2.6.1
Kafka version:

For specific cases also provide

Number of Brokers:
Number partitions for topic: 6

Include Sample Code to reproduce behavior
let consumer = new kafka.Consumer(client, topics, consumerOptions);

  consumer.on("message", (message)=> {
    const processedData = processMessage(message);
    if (processedData) {
      sendAndCommit(processedData, offset, message);
    }
  });

This is the consumer options :
consumerOptions:
groupId: testGroup
autoCommit: false
fetchMaxWaitMs: 30000
fetchMaxBytes: 1048576
encoding: utf8
fetchMinBytes: 500
requireAcks: 0
fromOffset: false
Include output with Debug turned on
Thanks for your contribution!

Try using a ConsumerGroup. Make sure you are using the same groupId. Hope that helps!


NIFI-13578 Add Schema Branch Name and Schema Version in ValidateRecord

Summary
NIFI-13578
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[X] Apache NiFi Jira issue created

Pull Request Tracking

[X] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[X] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[X] Pull Request based on current revision of the main branch
[X] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 21

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

Thank you for working on this @juldrixx. The addition of these properties seems coherent with other implementations.
Instead of re-declaring both SCHEMA_BRANCH_NAME and SCHEMA_VERSION we may want to use those properties as declared in the SchemaAccessUtils.
Other than that, the changes look good from my perspective. 👍🏻

Thank you for working on this @juldrixx. The addition of these properties seems coherent with other implementations.
Instead of re-declaring both SCHEMA_BRANCH_NAME and SCHEMA_VERSION we may want to use those properties as declared in the SchemaAccessUtils.
Other than that, the changes look good from my perspective. 👍🏻

It's impossible because the dependsOn needs SCHEMA_NAME_PROPERTY and  SCHEMA_TEXT_PROPERTY but SCHEMA_NAME_PROPERTY is different from the one in SchemaAccessUtils

You're absolutely right, I didn't notice that difference.
Do you think it makes sense to add a test, that uses the added properties to ensure they're properly integrated and not just made available for configuration?

You're absolutely right, I didn't notice that difference.
Do you think it makes sense to add a test, that uses the added properties to ensure they're properly integrated and not just made available for configuration?

I implemented the migrateProperties method to migrate to SchemaAccessUtils attributes.
I can try to add some unit test to check the update.

Besides the wording of the exception messages, the PR looks good to me now. Thank you for working on these improvements @juldrixx. 👍🏻
Just a minor hint towards contributing to the project. To ease the review of your contribution:

Please avoid using squash  or --force when making these changes, as it will overwrite the remote branch and reduce the capability to track these changes.

See the contribution guidelines for more details.

I usually do it this way, but I wanted to respect the “Pull Request refers to a feature branch with one commit containing changes” rule, so I looked at the other PRs and saw cases of push forces, so I thought that was the right thing to do.

Thanks for working on this improvement @juldrixx, I noted one general concern about the introduction of commons-lang3.

I'm not sure what is the change requested? And what is your concern?

Thanks for working on this improvement @juldrixx, I noted one general concern about the introduction of commons-lang3.

I'm not sure what is the change requested? And what is your concern? @exceptionfactory

@juldrixx Sorry about that, it looks like my code-level comment did not come through.
The concern there is introducing the commons-lang3 dependency just for the use of the Triple class. I recommend create a record that can be used to hold the values, avoiding the need for the commons-lang3 dependency.

Thanks for working on this improvement @juldrixx, I noted one general concern about the introduction of commons-lang3.

I'm not sure what is the change requested? And what is your concern? @exceptionfactory

@juldrixx Sorry about that, it looks like my code-level comment did not come through.
The concern there is introducing the commons-lang3 dependency just for the use of the Triple class. I recommend create a record that can be used to hold the values, avoiding the need for the commons-lang3 dependency.

Should be good now @exceptionfactory, I reproduced what was done for Tuple but for Triple.


column method from ID class should have guessColumn as backup

The ID class does not have access to the model, so it can't guess the column for the id. As the guess is to use $model->getRouteKeyName().
If you need to know the column name, the public Schema::idKeyName() method can be used.


Add native PG to IoT benchmark

Like with DevOps, I added the ability to use date_trunc instead of time_bucket for the IoT case.
NB: not sure about go.sum and go.mod files...

Will do, planned anyways to finish this, it's open for way too long now...

Hi @jonatas. I will make the changes; I am just not yet sure how quick I will be. Thanks a lot for the review!


stderror spamming console along CQR

Good morning, while trying to debug a crash i have for chocolate quest repoured since last update of both mods, i noticed these messages are spamming my console, as im not an expert i dont know if this may be related or is something i should worry about or something ill just have to ignore, would you help me providing me some information please?
this is the Std error message im getting:
https://pastebin.com/pW7dzhGK
Thanks in advance.
Im using geckolib-forge-1.12.2-3.0.11.jar
Edit:
also, found this when console stopped spamming messages:
https://pastebin.com/6TJgXMB2
it seems like .json animation by mobends cannot be loaded f or something, but then why is there a line referencing chocolate quest repoured? i dont understand

also, found this when console stopped spamming messages:
https://pastebin.com/6TJgXMB2

Yes, this and mobends with be incompatible due to it's use of an animations folder. This is the same as #187 and can not be fixed by us.


hover on macro variables (#xxxx)  to show description of it

First thank you for the extension. It works great.
Just one small question: would it be able to show the description of the macro variables when hovering on it? currently it displays the current value of the variables on hover.
We have a lot of macros for various machines and used a large amount of system variables or common variables in the macros. Each time when we edit or view a macro,  we have to search the manual for the meaning of the variables. It's really a pain. It would be a great help if we could somehow check the description of the variables within Vscode.
Thank you.

Thanks for the good word.
By system variables do you mean for example Fanuc system macro variables like shown below? https://www.machinetoolhelp.com/Applications/macro/system_variables.html
And what do you mean by common variables? It's another name for system variables or user defined variables?

yes.
local variable: #1 - #33
common variable ( user defined global variable) : #100 -#999
system variable: #1000 +


Fixtures are called too many times for concurrent tests when beforeEach uses a fixture

Describe the bug
If you have a fixture, a beforeEach hook and concurrent tests, the fixture will be called more times than expected. 2n-1 times to be precise, instead of N times.
While one could say it is expected, because vitest do not assume anything about your fixture, the fact that the behaviour differs between sequential and concurrent tests leads me to believe this is a bug.
Reproduction
See #4748
I've submitted a PR to illustrate the case, because it does not happen on Stackblitz.
System Info
System:
    OS: macOS 14.2
    CPU: (12) arm64 Apple M2 Max
    Memory: 26.31 GB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.13.0 - ~/.nvm/versions/node/v18.13.0/bin/node
    npm: 8.19.3 - ~/.nvm/versions/node/v18.13.0/bin/npm
    pnpm: 8.10.3 - ~/.nvm/versions/node/v18.13.0/bin/pnpm
    bun: 1.0.14 - ~/.bun/bin/bun
  Browsers:
    Chrome: 120.0.6099.109
    Edge: 120.0.2210.61
    Safari: 17.2
  npmPackages:
    @vitest/browser: workspace:* => 1.0.4
    @vitest/coverage-istanbul: workspace:* => 1.0.4
    @vitest/coverage-v8: workspace:* => 1.0.4
    @vitest/ui: workspace:* => 1.0.4
    vite: ^5.0.0 => 5.0.2
    vitest: workspace:* => 1.0.4

Used Package Manager
pnpm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Thanks for the repro PR!
I was trying to minimize the repro further down, but it turns out it still requires many factors to reproduce.
I also observed that it doesn't reliably happen on Stackblitz but it still happens once in a five times or so.
https://stackblitz.com/edit/vitest-dev-vitest-ttstfy?file=test%2Frepro.test.ts
I found that there is something suspicious with fixture cleanup, so I'm preparing a PR to fix this.


ML 2.12 : Implement Logistic Regression without using any standard ML library like scikit-learn or more. (D)

Description
📌  Issues for Week 2
Welcome to 'ML' Team, good to see you here
:arrow_forward: This issue will helps readers in acquiring all the knowledge that one needs to know about ----
Implement Logistic Regression without using any standard ML library like scikit-learn or more.
:red_circle: To get assigned to this issue, add your Batch Numbers mentioned in the spreadsheet of "Machine Learning", the approach one would follow and choice you prefer (Documentation, Audio, Video). You can go with all three or any number of options you're interested to work on.
✔ Domain : Machine Learning
:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.

"Issue Title" and "PR Title should be the same. Include issue number along with it.

Changes should be made inside the Machine Learning/Machine_Learning/Supervised_Machine_Learning Branch.

Follow Contributing Guidelines & Code of Conduct before start Contributing.

This issue is only for 'GWOC' contributors of 'Machine Learning' domain.

Dataset to be used : IRIS DATASET. (No other datasets will be entertained.)

:white_check_mark: To be Mentioned while taking the issue :

Full name
Batch Number
GitHub Profile Link
Which type of Contribution you want to make :

[ ] Documentation (Coding in .ipynb file, show the implementation)

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎
Domain
Machine Learning
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

Name: Hrugved Kolhe
Batch: 3
GitHub Profile
[x]  Documentation

/assign I can work on this

/assign

/assign
Can I work on it?
Name-Tanvi Deshmukh
batch-5
Contribution type: documentation

@divya-chhoriya This issue is assigned to you. Complete this by this Wednesday.

Name:Monal Singh
Batch no.:5
Github profile link: https://github.com/monalsingh10
Which type of contribution you want to make: Documentation


AppImage does not work

me@host:~$ '/home/me/Downloads/unofficial-desktop-for-ynab-0.1.0-x86_64.AppImage'
/tmp/.mount_YHsSU6
installed: X-AppImage-Version=<IP_ADDRESS> image: X-AppImage-Version=<IP_ADDRESS>
/tmp/.mount_YHsSU6/AppRun: line 50: /tmp/.mount_YHsSU6/usr/bin/unofficial-for-ynab: No such file or directory

Might be related to this.

Thanks for the heads up! Looks like that's exactly the cause.
When I do my next release I'll see if there's a new Electron Builder release I can take advantage of.

Should be fixed in electron-builder, https://github.com/electron-userland/electron-builder/issues/504#issuecomment-237814035


Feat feed

old connections-object collection is renamed as Deprecated
i tried to keep the old state structure as much as possible
important lookups (you'll need these when writing selectors):
state.getIn(['needs', 'ownNeeds', needUri, 'hasConnections']) // -> connectionUris
state.getIn(['needs', 'theirNeeds', needUri, 'hasConnections']) // -> connectionUris
state.getIn(['events', 'events', eventUri, 'hasReceiver']) // -> connectionUri
state.getIn(['events', 'events', eventUri, 'hasReceiverNeed']) // -> needUri
state.getIn(['connections', 'connections', connectionUri, 'belongsToNeed']) // -> needUri
state.getIn(['connections', 'connections', connectionUri, 'hasEvents']) // -> eventUris

when using unreadEvents try to just use the .uri-field and lookup the actual event in ['events', 'events']
I still need to remove anything using connectionsDeprecated and remove the superfluos load-actions. but the state is in the form it can remain in for now, imo.
As usual, don't delete the branch after merging, plz :)

Note: latest devel wasn't merged to this prior to the PR


How to save the subnet into a checkpoint？

Hi, this work is awesome and helps me a lot.  But I don't how to save the subnet into a checkpoint , could you provide some ways to get the checkpoint of subnet? Thanks a lot.

@Ref-rain Thanks for your attention! I noticed you have closed this issue. Did you solve this problem, or do you still need any help?

@Ref-rain Thanks for your attention! I noticed you have closed this issue. Did you solve this problem, or do you still need any help?

I have successfully exported it to onnx model， and the checkpoint for pytorch is not too necessary。Thanks for your apply.


Segfault from FFI closure function in interpreter

There is a bug causing a segmentation fault when using FFI closured function pointers in the interpreter.
A triggering example is XML.parse("<foo>"). The setup for libxml2 configures some function pointers for memory management via LibXML.xmlGcMemSetup.
These function pointers are then used from within libxml2 when it needs to allocate memory, for example. This happens when parsing an XML document. Apparently, the closured function that's supposed to be called from the closure wrapper is broken: The user_data pointer (which holds a reference to the interpreter and context instances) points to a very low address like 0x43 (c.f. Context.ffi_closure_fun).
I have been able to reproduce what looks like the same bug without libxml:
// libclosure.c
// build: gcc -shared -fPIC .test/lib_closure.c -o libclosure.so
int (*foo_ptr)(int);

void set_foo(int (*f)(int)) {
  foo_ptr = f;
}

#! bin/crystal i
@[Link("./libclosure.so")]
lib LibClosure
  fun set_foo(fun_ptr : LibC::Int -> LibC::Int) : Void

  $foo_ptr : LibC::Int -> LibC::Int
end

LibClosure.set_foo -> (i : LibC::Int) { i * 100 }
LibClosure.foo_ptr.pointer # => Pointer(Void)@0x7f1ad3d98f40
LibClosure.foo_ptr.call(4) # Error: Invalid memory access (signal 11) at address 0x0

It seems to be working fine when the function pointer in a global variable is called from another C function like this:
int call_foo_ptr() {
  (*foo_ptr)(42);
}

When the value of the global variable is assigned from Crystal, it can be called from Crystal. But now it errors when called from C:
LibClosure.foo_ptr = -> (i : LibC::Int) { i * 100 }
LibClosure.foo_ptr.call(4) # => 400
LibClosure.foo_ptr.pointer # => Pointer(Void)@0x7fd71f787180
LibClosure.call_foo_ptr # Error: Invalid memory access (signal 11) at address 0x7fd71f787180

Note that here the address of the function pointer triggers the invalid access.

I'll try to reproduce this later, but in the meantime: does it also crash if you run it with GC_DONT_GC=1 ?

I think I know what this is...
A Proc in Crystal is a pair of {pointer, data}. When we send a Proc to C we want to only keep the pointer value (and check that data is null, otherwise we are passing a closure.)
It seems doing these checks is missing in the "external_var_set" primitive:
https://github.com/crystal-lang/crystal/blob/37497c9ef2bbfd552e53f1a8463f70a421c4b50d/src/compiler/crystal/interpreter/primitives.cr#L295-L309
A similar thing must be done when you send a Proc to a C struct field. In that case that's already handled by the interpreter:
https://github.com/crystal-lang/crystal/blob/37497c9ef2bbfd552e53f1a8463f70a421c4b50d/src/compiler/crystal/interpreter/primitives.cr#L341-L346
So I think if we also do that check in "external_var_set", everything will start working fine.
That said, I can't remember how reading the value works... maybe it doesn't work! I think when we read the value we get a pointer, I'm not sure where that is wrapped in a Proc 🤔  (not sure if this even works in compiled mode, probably yes)

For compiled mode we are doing it here when we read an instance var:
https://github.com/crystal-lang/crystal/blob/37497c9ef2bbfd552e53f1a8463f70a421c4b50d/src/compiler/crystal/codegen/codegen.cr#L1272-L1278
So we must do the same thing in the interpreter, but I think it's missing...
That said, if all we need for now is to write the Proc but not read it, just doing the change in "external_var_set" might be enough for now. Of course we'd like to do things well when reading too, but it could be done later.

Thanks @asterite, that's really helpful. However, the problem for libxml2 is not about writing to an external var from Crystal. The proc is passed to a function (xmlGcMemSetup) and that function assigns it to a global var. Passing a proc to a lib function apparently works fine. If you call the function pointer directly, there's no issue:
Example:
int call_foo(int (*fun_ptr)(int)) {
  return (*fun_ptr)(12);
}

LibClosure.call_foo -> (i : LibC::Int) { i * 10 } # => 120

The problem seems to exist when the function pointer is assigned to a global var in the C library, and then later accessed from a Crystal context.
In my isolated test, it also worked when the global var function pointer is called from a lib function. However, in the case of libxml2, that's exactly what happens, but it fails.

Then I think I'm not understanding something. In all the code snippets above you always get a segfault. So what's the code that doesn't segfault?
My guess is that if it doesn't segfault it's by pure chance.

The problem seems to exist when the function pointer is assigned to a global var in the C library, and then later accessed from a Crystal context

Right, that same conversion of C function to Crystal Proc is missing from "external_var_get"
is that the problem?

To clarify, when we read a global variable of type Proc from C, we just get a pointer value. We must convert that to a tuple that has that pointer value followed by a zero, which is the closure data.

So what's the code that doesn't segfault?

The example in my last comment (https://github.com/crystal-lang/crystal/issues/11802#issuecomment-1030406795): When a function pointer is passed to a C function and called from there directly, it seems to work.
This leads me to believe there is something wrong with storing function pointers. But it's not only happening in Crystal land.

The main thing to know about these things is that sometimes you do something and it might work almost by chance, but in some cases segfault. For example you might get the pointer data well but also write over incorrect stack data, then eventually you get a crash.
If you could write some specs that are currently failing, I'll fix this on Monday.

I tried to reproduce this but the interpreter isn't working for me at all. It can't find pthread. If I don't link to pthread it can't find iconv. If I remove iconv it can't find dl.
I don't know what happened, everything was working fine for me. I guess I still don't understand how "something works but not exactly like compiled mode" is worse then "nothing is working" :-(

Could we at least add an option to load the current program's symbols so that at least I can contribute to the interpreter? I'm not sure what change I need to do... I also see there's load_current_program_handle and it's being called, but I don't know what it's not working...

Sorry to hear that the interpreter is broken for you. Could you look into #11792 or open a separate issue? I'm happy to help sort this out, but we shouldn't spam this discussion here.

Right, sorry. Also it's not that important. I'll take a look, thanks!

I pushed the test cases here: https://github.com/crystal-lang/crystal/tree/fix/interpreter-lib-function-pointer
The last two examples reproduce the error. The use case in libxml should be more like the third example ("passes function pointer and calls it later"), but that works fine in the specs. Maybe that's just by accident as you mentioned.

For me "passes function pointer and calls it later" fails:
Failures:

  1) Crystal::Repl::Interpreter function pointers passes function pointer and calls it later
     Failure/Error: interpret(<<-CR).should eq 420

       Expected: 420
            got: 32658

     # spec/compiler/interpreter/lib_spec.cr:86

Oh, it's because the C file is wrong. Don't you get this when you compile the lib?
spec/compiler/data/libs/funptr.c:13:1: warning: non-void function does not return a value [-Wreturn-type]

A return is missing in funptr_call:
int funptr_call() {
  return (*fun_ptr)(42); // In your branch this return is missing
}

Maybe your C compiler adds a return 🤷

By the way, the third example works fine and it's not by accident. We are already converting the Proc to a C function, as seen by disassembling the code (I made a change so that lib functions show nicer, I'll push that together with the eventual fix):
0000 put_i64<PHONE_NUMBER>
0010 put_i64 0
0020 proc_to_c_fun <ffi_call_interface>      # Here we turn the two values above into just one value
0030 lib_call LibFun#funptr_set
0040 pop 0
0046 lib_call LibFun#funptr_call
0056 leave 8

@straight-shoota Here's the fix:
diff --git a/src/compiler/crystal/interpreter/instructions.cr b/src/compiler/crystal/interpreter/instructions.cr
index 78b121625..1b96a9b48 100644
--- a/src/compiler/crystal/interpreter/instructions.cr
+++ b/src/compiler/crystal/interpreter/instructions.cr
@@ -1222,6 +1222,9 @@ require "./repl"
       lib_call: {
         operands:   [lib_function : LibFunction],
         code:       lib_call(lib_function),
+        disassemble: {
+          lib_function: "#{lib_function.def.owner}##{lib_function.def.name}",
+        },
       },
       leave: {
         operands:   [size : Int32],
diff --git a/src/compiler/crystal/interpreter/primitives.cr b/src/compiler/crystal/interpreter/primitives.cr
index f36b889ba..ad285f726 100644
--- a/src/compiler/crystal/interpreter/primitives.cr
+++ b/src/compiler/crystal/interpreter/primitives.cr
@@ -291,7 +291,14 @@ class Crystal::Repl::Compiler
       put_u64 fn.address, node: node

       # Read from the pointer
-      pointer_get(inner_sizeof_type(node), node: node)
+      if external.type.is_a?(ProcInstanceType)
+        # When reading a Proc from C, we read a function pointer:
+        # we need to convert that to a Proc
+        pointer_get(sizeof(Void*), node: node)
+        c_fun_to_proc node: node
+      else
+        pointer_get(inner_sizeof_type(node), node: node)
+      end
     when "external_var_set"
       external = node.target_def.as(External)

@@ -300,13 +307,24 @@ class Crystal::Repl::Compiler
       request_value(arg)
       dup(aligned_sizeof_type(arg), node: nil) if @wants_value

+      # When assigning a proc to an extern var we need
+      # to remove the closure data part.
+      arg_type = arg.type
+      if arg_type.is_a?(ProcInstanceType)
+        proc_to_c_fun arg_type.ffi_call_interface, node: nil
+      end
+
       fn = @context.c_function(external.real_name)

       # Put the symbol address, which is a pointer
       put_u64 fn.address, node: node

       # Set the pointer's value
-      pointer_set(inner_sizeof_type(node), node: node)
+      if arg_type.is_a?(ProcInstanceType)
+        pointer_set(sizeof(Void*), node: node)
+      else
+        pointer_set(inner_sizeof_type(node), node: node)
+      end
     when "struct_or_union_set"
       obj = obj.not_nil!
       arg = node.args.first

Note that:

We are still missing a similar c_fun_to_proc thing when reading from an @[Extern] struct whose field is of Proc type (I can fix that later, separately)
The libxml case is already handled well, so the segfault we are seeing might not be related to all of this. But we can see once this patch is in place!

This pending spec triggers the error: https://github.com/crystal-lang/crystal/blob/f22ad70ef3611f305c81af39ccce620f554c90a9/spec/compiler/interpreter/integration_spec.cr#L116
I noticed with the patch, the following code triggers an ICE in the interpreter:
lib LibXML
  fun xmlGcMemSetup(free_func : Void* ->,
                    malloc_func : LibC::SizeT -> Void*,
                    malloc_atomic_func : LibC::SizeT -> Void*,
                    realloc_func : Void*, LibC::SizeT -> Void*,
                    strdup_func : UInt8* -> UInt8*) : LibC::Int

  $xmlMalloc : LibC::SizeT -> Void*
end

LibXML.xmlGcMemSetup(
  ->GC.free,
  ->GC.malloc(LibC::SizeT),
  ->GC.malloc(LibC::SizeT),
  ->GC.realloc(Void*, LibC::SizeT),
  ->(str) {
    len = LibC.strlen(str) + 1
    copy = Pointer(UInt8).malloc(len)
    copy.copy_from(str, len)
    copy
  }
)

LibXML.xmlMalloc.pointer # KeyError: Missing hash key: Pointer(Void)@0x7fcebab3e260

Apparently the proc lookup from C function pointer doesn't work. The pointer value passed to xmlGcMemSetup is actually 0x7fcec24eef80. The error message appears to be loading a function pointer from 0x7fcebab3e260.

After making libxml2 and pthread work on my machine, both that spec and the snippet above work fine for me. Maybe this is something exclusive to unix? Do you have a mac to try it on?
All of this is with the patch I sent above.

Do you happen to be on a 32 bits machine?

If you run this through the interpreter:
lib LibXML
  fun xmlGcMemSetup(free_func : Void* ->,
                    malloc_func : LibC::SizeT -> Void*,
                    malloc_atomic_func : LibC::SizeT -> Void*,
                    realloc_func : Void*, LibC::SizeT -> Void*,
                    strdup_func : UInt8* -> UInt8*) : LibC::Int

  $xmlMalloc : LibC::SizeT -> Void*
end

malloc = ->GC.malloc(LibC::SizeT)
p malloc.pointer

LibXML.xmlGcMemSetup(
  ->GC.free,
  malloc,
  malloc,
  ->GC.realloc(Void*, LibC::SizeT),
  ->(str) {
    len = LibC.strlen(str) + 1
    copy = Pointer(UInt8).malloc(len)
    copy.copy_from(str, len)
    copy
  }
)

p LibXML.xmlMalloc.pointer

What do you get? I get the same values in both p.

By the way, here's the full diff I have locally:
diff --git a/spec/compiler/interpreter/integration_spec.cr b/spec/compiler/interpreter/integration_spec.cr
index 2a7fa592e..fe5649815 100644
--- a/spec/compiler/interpreter/integration_spec.cr
+++ b/spec/compiler/interpreter/integration_spec.cr
@@ -83,7 +83,7 @@ describe Crystal::Repl::Interpreter do
       CODE
     end

-    pending "does YAML" do
+    it "does YAML" do
       interpret(<<-CODE, prelude: "prelude").should eq("6")
         require "yaml"

@@ -97,7 +97,7 @@ describe Crystal::Repl::Interpreter do
       CODE
     end

-    pending "does YAML::Serializable" do
+    it "does YAML::Serializable" do
       interpret(<<-CODE, prelude: "prelude").should eq("3")
         require "yaml"

@@ -113,7 +113,7 @@ describe Crystal::Repl::Interpreter do
       CODE
     end

-    pending "does XML" do
+    it "does XML" do
       interpret(<<-CODE, prelude: "prelude").should eq("3")
         require "xml"

diff --git a/spec/compiler/interpreter/lib_spec.cr b/spec/compiler/interpreter/lib_spec.cr
index ef4a51a91..e20837fdd 100644
--- a/spec/compiler/interpreter/lib_spec.cr
+++ b/spec/compiler/interpreter/lib_spec.cr
@@ -54,4 +54,72 @@ describe Crystal::Repl::Interpreter do
       FileUtils.rm_rf(SPEC_CRYSTAL_LOADER_LIB_PATH)
     end
   end
+
+  describe "function pointers" do
+    before_all do
+      FileUtils.mkdir_p(SPEC_CRYSTAL_LOADER_LIB_PATH)
+      build_c_dynlib(compiler_datapath("libs", "funptr.c"))
+    end
+
+    it "passes function pointer to function" do
+      interpret(<<-CR).should eq 120
+        @[Link(ldflags: "-L#{SPEC_CRYSTAL_LOADER_LIB_PATH} -lfunptr")]
+        lib LibFun
+          fun funptr(f : Int32 -> Int32) : Int32
+        end
+        LibFun.funptr -> (i : Int32) { i * 10 }
+        CR
+    end
+
+    it "assigns function pointer to global var" do
+      interpret(<<-CR).should eq 120
+        @[Link(ldflags: "-L#{SPEC_CRYSTAL_LOADER_LIB_PATH} -lfunptr")]
+        lib LibFun
+          $fun_ptr : Int32 -> Int32
+        end
+        LibFun.fun_ptr = -> (i : Int32) { i * 10 }
+        LibFun.fun_ptr.call(12)
+        CR
+    end
+
+    it "passes function pointer and calls it later" do
+      interpret(<<-CR).should eq 420
+        @[Link(ldflags: "-L#{SPEC_CRYSTAL_LOADER_LIB_PATH} -lfunptr")]
+        lib LibFun
+          fun funptr_set(f : Int32 -> Int32) : Void
+          fun funptr_call : Int32
+        end
+        LibFun.funptr_set -> (i : Int32) { i * 10 }
+        LibFun.funptr_call
+        CR
+    end
+
+    it "assigns function pointer to global var and calls it later" do
+      interpret(<<-CR).should eq 420
+        @[Link(ldflags: "-L#{SPEC_CRYSTAL_LOADER_LIB_PATH} -lfunptr")]
+        lib LibFun
+          $fun_ptr : Int32 -> Int32
+          fun funptr_call : Int32
+        end
+        LibFun.fun_ptr = -> (i : Int32) { i * 10 }
+        LibFun.funptr_call
+        CR
+    end
+
+    it "passes function pointer to function var and reads it from global var" do
+      interpret(<<-CR).should eq 420
+        @[Link(ldflags: "-L#{SPEC_CRYSTAL_LOADER_LIB_PATH} -lfunptr")]
+        lib LibFun
+          $fun_ptr : Int32 -> Int32
+          fun funptr_set(f : Int32 -> Int32) : Void
+        end
+        LibFun.funptr_set -> (i : Int32) { i * 10 }
+        LibFun.fun_ptr.call(42)
+        CR
+    end
+
+    after_all do
+      FileUtils.rm_rf(SPEC_CRYSTAL_LOADER_LIB_PATH)
+    end
+  end
 end
diff --git a/spec/compiler/loader/spec_helper.cr b/spec/compiler/loader/spec_helper.cr
index deae47b63..e11b7c434 100644
--- a/spec/compiler/loader/spec_helper.cr
+++ b/spec/compiler/loader/spec_helper.cr
@@ -9,6 +9,6 @@ def build_c_dynlib(c_filename, target_dir = SPEC_CRYSTAL_LOADER_LIB_PATH)
   {% if flag?(:msvc) %}
     `cl.exe /nologo /LD #{Process.quote(c_filename)} #{Process.quote("/Fo#{o_filename}")}`.should be_truthy
   {% else %}
-    `#{ENV["CC"]? || "cc"} -shared #{Process.quote(c_filename)} -o #{Process.quote(o_filename)}`.should be_truthy
+    `#{ENV["CC"]? || "cc"} -fPIC -shared #{Process.quote(c_filename)} -o #{Process.quote(o_filename)}`.should be_truthy
   {% end %}
 end
diff --git a/src/compiler/crystal/interpreter/context.cr b/src/compiler/crystal/interpreter/context.cr
index c52effd3d..f37726906 100644
--- a/src/compiler/crystal/interpreter/context.cr
+++ b/src/compiler/crystal/interpreter/context.cr
@@ -363,15 +363,13 @@ class Crystal::Repl::Context
     # with the compiler's own GC.
     args.delete("-lgc")

-    Crystal::Loader.parse(args).tap do |loader|
-      # FIXME: Part 2: This is a workaround for initial integration of the interpreter:
-      # We append a handle to the current executable (i.e. the compiler program)
-      # to the loader's handle list. This gives the loader access to all the symbols in the compiler program,
-      # including those from statically linked libraries like libgc.
-      # This probably won't work for a fully statically linked compiler.
-      # But `Crystal::Loader` currently doesn't support that anyways.
-      loader.load_current_program_handle
-    end
+    # FIXME: Part 2: This is a workaround for initial integration of the interpreter:
+    # We append a handle to the current executable (i.e. the compiler program)
+    # to the loader's handle list. This gives the loader access to all the symbols in the compiler program,
+    # including those from statically linked libraries like libgc.
+    # This probably won't work for a fully statically linked compiler.
+    # But `Crystal::Loader` currently doesn't support that anyways.
+    Crystal::Loader.parse(args, load_current_program_handle: true)
   }

   def c_function(name : String)
diff --git a/src/compiler/crystal/interpreter/instructions.cr b/src/compiler/crystal/interpreter/instructions.cr
index 78b121625..1b96a9b48 100644
--- a/src/compiler/crystal/interpreter/instructions.cr
+++ b/src/compiler/crystal/interpreter/instructions.cr
@@ -1222,6 +1222,9 @@ require "./repl"
       lib_call: {
         operands:   [lib_function : LibFunction],
         code:       lib_call(lib_function),
+        disassemble: {
+          lib_function: "#{lib_function.def.owner}##{lib_function.def.name}",
+        },
       },
       leave: {
         operands:   [size : Int32],
diff --git a/src/compiler/crystal/interpreter/primitives.cr b/src/compiler/crystal/interpreter/primitives.cr
index f36b889ba..ad285f726 100644
--- a/src/compiler/crystal/interpreter/primitives.cr
+++ b/src/compiler/crystal/interpreter/primitives.cr
@@ -291,7 +291,14 @@ class Crystal::Repl::Compiler
       put_u64 fn.address, node: node

       # Read from the pointer
-      pointer_get(inner_sizeof_type(node), node: node)
+      if external.type.is_a?(ProcInstanceType)
+        # When reading a Proc from C, we read a function pointer:
+        # we need to convert that to a Proc
+        pointer_get(sizeof(Void*), node: node)
+        c_fun_to_proc node: node
+      else
+        pointer_get(inner_sizeof_type(node), node: node)
+      end
     when "external_var_set"
       external = node.target_def.as(External)

@@ -300,13 +307,24 @@ class Crystal::Repl::Compiler
       request_value(arg)
       dup(aligned_sizeof_type(arg), node: nil) if @wants_value

+      # When assigning a proc to an extern var we need
+      # to remove the closure data part.
+      arg_type = arg.type
+      if arg_type.is_a?(ProcInstanceType)
+        proc_to_c_fun arg_type.ffi_call_interface, node: nil
+      end
+
       fn = @context.c_function(external.real_name)

       # Put the symbol address, which is a pointer
       put_u64 fn.address, node: node

       # Set the pointer's value
-      pointer_set(inner_sizeof_type(node), node: node)
+      if arg_type.is_a?(ProcInstanceType)
+        pointer_set(sizeof(Void*), node: node)
+      else
+        pointer_set(inner_sizeof_type(node), node: node)
+      end
     when "struct_or_union_set"
       obj = obj.not_nil!
       arg = node.args.first
diff --git a/src/compiler/crystal/loader.cr b/src/compiler/crystal/loader.cr
index 286067e4e..567343012 100644
--- a/src/compiler/crystal/loader.cr
+++ b/src/compiler/crystal/loader.cr
@@ -32,14 +32,17 @@ class Crystal::Loader
     end
   end

-  def self.new(search_paths : Array(String), libnames : Array(String), file_paths : Array(String)) : self
+  def self.new(search_paths : Array(String), libnames : Array(String), file_paths : Array(String), *, load_current_program_handle : Bool = false) : self
     loader = new(search_paths)
+    if load_current_program_handle
+      loader.load_current_program_handle
+    end

     file_paths.each do |path|
       loader.load_file(::Path[path].expand)
     end
     libnames.each do |libname|
-      loader.load_library(libname)
+      loader.load_library?(libname)
     end
     loader
   end
diff --git a/src/compiler/crystal/loader/unix.cr b/src/compiler/crystal/loader/unix.cr
index 85b64a3a0..404e143a6 100644
--- a/src/compiler/crystal/loader/unix.cr
+++ b/src/compiler/crystal/loader/unix.cr
@@ -27,7 +27,7 @@ class Crystal::Loader
                              {% end %}

   # Parses linker arguments in the style of `ld`.
-  def self.parse(args : Array(String), *, search_paths : Array(String) = default_search_paths) : self
+  def self.parse(args : Array(String), *, search_paths : Array(String) = default_search_paths, load_current_program_handle : Bool = false) : self
     libnames = [] of String
     file_paths = [] of String

@@ -48,7 +48,7 @@ class Crystal::Loader
     end

     begin
-      self.new(search_paths, libnames, file_paths)
+      self.new(search_paths, libnames, file_paths, load_current_program_handle: load_current_program_handle)
     rescue exc : LoadError
       exc.args = args
       exc.search_paths = search_paths
@@ -91,11 +91,15 @@ class Crystal::Loader
   def self.default_search_paths : Array(String)
     default_search_paths = [] of String

-    if env_library_path = ENV[{{ flag?(:darwin) ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH" }}]?
+    env_library_path = ENV[{{ flag?(:darwin) ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH" }}]?
+
+    if env_library_path
       # TODO: Expand tokens $ORIGIN, $LIB, $PLATFORM
       default_search_paths.concat env_library_path.split(Process::PATH_DELIMITER, remove_empty: true)
     end

+    default_search_paths << "/usr/local/opt/libxml2/lib"
+
     {% if flag?(:linux) || flag?(:bsd) %}
       read_ld_conf(default_search_paths)
     {% end %}

With that, all the integration specs pass, and the snippet above doesn't give an error.
It would also be nice to see the full stack trace of that KeyError you are getting.

I found it 🚀
Your test code was almost exactly identical to mine, but yours worked for me too, mine didn't. One of the differences was the link annotation (@[Link("xml2", pkg_config: "libxml-2.0")]) which is missing in your example. However, that shouldn't really work because when there's no link annotation for LibXML, the loader wouldn't know what to look for.
As it happens, this is a use case where the loader should be more strict but isn't. Compiling your example results in a link error because libxml2 isn't linked. In the interpreter it works because the compiler's symbols are loaded and for some reason, the compiler links against libxml2 (apparently through libLLVM 🤷).
Thus, when my example loads libxml2 via the interpreter, we have two versions of the library loaded (and maybe even different ones because I used a dev build for debugging). As a result, global variables seem to get messed up - I suppose this is to be expected then.

I tried to deactivate the libxml2 initialization in interpreted mode. Still fails. Might be caused by GC conflicts between interpreted program and compiler.
https://github.com/straight-shoota/crystal/pull/new/wip/interpreter-libxml2

This issue still broken even i don't need pressing Ctrl+d after i input Time.local immediately.
╰─ $ 11  cry i
icr:1:0> Time.local
=> Invalid memory access (signal 11) at address 0x43
[0x564ffe9e7986] *Exception::CallStack::print_backtrace:Nil +118 in crystal
[0x564ffe9be0a6] ~procProc(Int32, Pointer(LibC::SiginfoT), Pointer(Void), Nil) +310 in crystal
[0x7f977443e8e0] ?? +140288467396832 in /usr/lib/libc.so.6
[0x564fff804e17] *Crystal::Repl::Context::ffi_closure_fun<Pointer(Crystal::LibFFI::Cif), Pointer(Void), Pointer(Pointer(Void)), Pointer(Void)>:Pointer(UInt8) +55 in crystal
[0x564ffe9d2736] ~procProc(Pointer(Crystal::LibFFI::Cif), Pointer(Void), Pointer(Pointer(Void)), Pointer(Void), Nil) +6 in crystal
[0x7f977b4fa0fb] ?? +140288585605371 in /usr/lib/libffi.so.8
[0x7f977b4fa758] ?? +140288585607000 in /usr/lib/libffi.so.8
[0x564fffde0eae] GC_invoke_finalizers +158 in crystal
[0x564fffde0ffe] GC_notify_or_invoke_finalizers +174 in crystal
[0x564fffde2f26] GC_generic_malloc_many +150 in crystal
[0x564fffdefc1e] GC_malloc_kind +190 in crystal
[0x564ffeaac7c6] *GC::malloc<UInt64>:Pointer(Void) +6 in crystal
[0x564ffe99da1e] __crystal_malloc64 +14 in crystal
[0x564fff67fda1] *Array(Crystal::While) +17 in crystal
[0x564fff657dfe] *Crystal::MainVisitor#initialize<Crystal::Program, Hash(String, Crystal::MetaVar), Crystal::Def, Nil>:Hash(String, Crystal::MetaVar) +94 in crystal
[0x564fff657d8f] *Crystal::MainVisitor#initialize<Crystal::Program, Hash(String, Crystal::MetaVar), Crystal::Def>:Hash(String, Crystal::MetaVar) +47 in crystal
[0x564fff657d55] *Crystal::MainVisitor::new<Crystal::Program, Hash(String, Crystal::MetaVar), Crystal::Def>:Crystal::MainVisitor +181 in crystal
[0x564ffed59716] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +6806 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed35272] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +1714 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff669aba] *Crystal::MainVisitor#type_assign<Crystal::Var+, Crystal::ASTNode+, Crystal::Assign, Nil>:(Crystal::MetaVar | Nil) +58 in crystal
[0x564fff669a6f] *Crystal::MainVisitor#type_assign<Crystal::Var+, Crystal::ASTNode+, Crystal::Assign>:(Crystal::MetaVar | Nil) +47 in crystal
[0x564fff66979c] *Crystal::MainVisitor#visit<Crystal::Assign>:Bool +108 in crystal
[0x564ffed6fca9] *Crystal::ASTNode+ +1945 in crystal
[0x564fff66dc2e] *Crystal::MainVisitor#visit<Crystal::If>:Bool +110 in crystal
[0x564ffed700f2] *Crystal::ASTNode+ +3042 in crystal
[0x564fff665def] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +255 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed34eca] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +778 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed34eca] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +778 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff665def] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +255 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed34eca] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +778 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed35272] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +1714 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff66dd61] *Crystal::MainVisitor#visit<Crystal::If>:Bool +417 in crystal
[0x564ffed700f2] *Crystal::ASTNode+ +3042 in crystal
[0x564fff665dab] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +187 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564fff679c47] *Crystal::MainVisitor#expand<Crystal::Case>:Bool +71 in crystal
[0x564fff679992] *Crystal::MainVisitor#visit<Crystal::Case>:Bool +130 in crystal
[0x564ffed70c03] *Crystal::ASTNode+ +5875 in crystal
[0x564fff66dd61] *Crystal::MainVisitor#visit<Crystal::If>:Bool +417 in crystal
[0x564ffed700f2] *Crystal::ASTNode+ +3042 in crystal
[0x564fff679c47] *Crystal::MainVisitor#expand<Crystal::Case>:Bool +71 in crystal
[0x564fff679992] *Crystal::MainVisitor#visit<Crystal::Case>:Bool +130 in crystal
[0x564ffed70c03] *Crystal::ASTNode+ +5875 in crystal
[0x564fff665def] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +255 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed35272] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +1714 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff669aba] *Crystal::MainVisitor#type_assign<Crystal::Var+, Crystal::ASTNode+, Crystal::Assign, Nil>:(Crystal::MetaVar | Nil) +58 in crystal
[0x564fff669a6f] *Crystal::MainVisitor#type_assign<Crystal::Var+, Crystal::ASTNode+, Crystal::Assign>:(Crystal::MetaVar | Nil) +47 in crystal
[0x564fff66979c] *Crystal::MainVisitor#visit<Crystal::Assign>:Bool +108 in crystal
[0x564ffed6fca9] *Crystal::ASTNode+ +1945 in crystal
[0x564fff665def] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +255 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564fff66ff9f] *Crystal::MainVisitor#visit<Crystal::While>:(Bool | Nil) +1839 in crystal
[0x564ffed7015a] *Crystal::ASTNode+ +3146 in crystal
[0x564fff665dab] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +187 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed34eca] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +778 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff665dab] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +187 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed34eca] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +778 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed35272] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +1714 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff665def] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +255 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed35272] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +1714 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff665dab] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +187 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed35272] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +1714 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff5ce105] *Crystal::MainVisitor+ +2805 in crystal
[0x564ffee68a42] *Crystal::Block +50 in crystal
[0x564fff66b0f0] *Crystal::MainVisitor#visit<Crystal::Yield>:Bool +1536 in crystal
[0x564ffed6fd11] *Crystal::ASTNode+ +2049 in crystal
[0x564fff5ce105] *Crystal::MainVisitor+ +2805 in crystal
[0x564ffee68a42] *Crystal::Block +50 in crystal
[0x564fff66b0f0] *Crystal::MainVisitor#visit<Crystal::Yield>:Bool +1536 in crystal
[0x564ffed6fd11] *Crystal::ASTNode+ +2049 in crystal
[0x564fff665def] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +255 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed34eca] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +778 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff665dab] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +187 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed34eca] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +778 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564ffed5991c] *Crystal::Call#instantiate<Crystal::CallSignature, Crystal::Matches, Crystal::Type+, Nil, Bool>:Array(Crystal::Def+) +7324 in crystal
[0x564ffed52cf1] *Crystal::Call#lookup_matches_in_type<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool, Bool>:Array(Crystal::Def+) +8305 in crystal
[0x564ffed50c73] *Crystal::Call#lookup_matches_in_type:search_in_parents:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +115 in crystal
[0x564ffed50bfc] *Crystal::Call#lookup_matches_in<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Nil, String, Bool, Bool>:Array(Crystal::Def+) +28 in crystal
[0x564ffed5a445] *Crystal::Call#lookup_matches_in:with_autocast<Crystal::Type+, Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +805 in crystal
[0x564ffed34eca] *Crystal::Call#lookup_matches_without_splat<Array(Crystal::Type+), (Array(Crystal::NamedArgumentType) | Nil), Bool>:Array(Crystal::Def+) +778 in crystal
[0x564ffed34113] *Crystal::Call#lookup_matches:with_autocast<Bool>:Array(Crystal::Def+) +723 in crystal
[0x564ffed33dd5] *Crystal::Call#lookup_matches:Array(Crystal::Def+) +21 in crystal
[0x564ffed126b0] *Crystal::Call#recalculate:Nil +1840 in crystal
[0x564fff667631] *Crystal::MainVisitor#recalculate_call<Crystal::Call>:Nil +17 in crystal
[0x564fff661124] *Crystal::MainVisitor#visit<Crystal::Call>:Bool +2868 in crystal
[0x564ffed6feb9] *Crystal::ASTNode+ +2473 in crystal
[0x564fff665dab] *Crystal::MainVisitor#visit<Crystal::Expressions>:Bool +187 in crystal
[0x564ffed6fc41] *Crystal::ASTNode+ +1841 in crystal
[0x564ffebf8451] *Crystal::Program#visit_main:process_finished_hooks:cleanup:visitor<Crystal::ASTNode+, Bool, Bool, Crystal::MainVisitor>:Crystal::ASTNode+ +65 in crystal
[0x564ffebeb566] *Crystal::Program#semantic:main_visitor<Crystal::ASTNode+, Crystal::MainVisitor>:Crystal::ASTNode+ +1558 in crystal
[0x564fffb6a5e5] *Crystal::Repl::Value#to_s<IO::FileDescriptor>:(IO::FileDescriptor | Nil) +869 in crystal
[0x564ffeb65503] *IO::FileDescriptor +67 in crystal
[0x564ffeb654ad] *IO::FileDescriptor +77 in crystal
[0x564ffe9d27c9] *puts<Crystal::Repl::Value>:Nil +137 in crystal
[0x564fffd9ce8d] *Crystal::Repl#run:Nil +2045 in crystal
[0x564fffce193a] *Crystal::Command#repl:(Crystal::Repl::Value | Nil) +74 in crystal
[0x564fffcdc6f1] *Crystal::Command#run:(Bool | Crystal::Repl::Value | Nil) +1409 in crystal
[0x564fffcdbffb] *Crystal::Command::run<Array(String)>:(Bool | Crystal::Repl::Value | Nil) +43 in crystal
[0x564fffcdbf6e] *Crystal::Command::run:(Bool | Crystal::Repl::Value | Nil) +46 in crystal
[0x564ffe99d958] __crystal_main +2536 in crystal
[0x564ffeb88163] *Crystal::main_user_code<Int32, Pointer(Pointer(UInt8))>:Nil +19 in crystal
[0x564ffeb880b9] *Crystal::main<Int32, Pointer(Pointer(UInt8))>:Int32 +41 in crystal
[0x564ffe9aad46] main +6 in crystal
[0x7f9774429290] ?? +140288467309200 in /usr/lib/libc.so.6
[0x7f977442934a] __libc_start_main +138 in /usr/lib/libc.so.6
[0x564ffe99ce95] _start +37 in crystal
[0x0] ???

Test on version:
 ╰─ $ 11  cry version
Crystal 1.5.0-dev [ff55fb1bb] (2022-06-22)

LLVM: 13.0.1
Default target: x86_64-pc-linux-gnu

Just a note that it works fine for me on Mac 🤷

Here is a easy to reproduce issue for REPL FFI issue (i guess)
 ╰─ $ crystal i
icr:1:0> Time.local
=> 2022-06-15 22:15:54.441738959 +08:00 Asia/Shanghai
icr:2:0> Invalid memory access (signal 11) at address 0x43
[0x564dd835ed76] *Exception::CallStack::print_backtrace:Nil +118 in crystal
[0x564dd832c2fa] ~procProc(Int32, Pointer(LibC::SiginfoT), Pointer(Void), Nil) +330 in crystal
[0x7fd8126848e0] ?? +140565998487776 in /usr/lib/libc.so.6
[0x564dd91fcc67] *Crystal::Repl::Context::ffi_closure_fun<Pointer(Crystal::LibFFI::Cif), Pointer(Void), Pointer(Pointer(Void)), Pointer(Void)>:Pointer(UInt8) +55 in crystal
[0x564dd8349056] ~procProc(Pointer(Crystal::LibFFI::Cif), Pointer(Void), Pointer(Pointer(Void)), Pointer(Void), Nil) +6 in crystal
[0x7fd81287b0fb] ?? +140566000546043 in /usr/lib/libffi.so.8
[0x7fd81287b758] ?? +140566000547672 in /usr/lib/libffi.so.8
[0x564dd980472e] GC_invoke_finalizers +158 in crystal
[0x564dd980487e] GC_notify_or_invoke_finalizers +174 in crystal
[0x564dd98067a6] GC_generic_malloc_many +150 in crystal
[0x564dd981349e] GC_malloc_kind +190 in crystal
[0x564dd842bff6] *GC::malloc<UInt64>:Pointer(Void) +6 in crystal
[0x564dd8309c6e] __crystal_malloc64 +14 in crystal
[0x564dd8f50dc3] *Pointer(Hash::Entry(String, Crystal::MetaTypeVar)) +131 in crystal
[0x564dd8f4f581] *Hash(String, Crystal::MetaTypeVar) +17 in crystal
[0x564dd8f4f02d] *Hash(String, Crystal::MetaTypeVar) +77 in crystal
[0x564dd8f4efd3] *Hash(String, Crystal::MetaTypeVar) +51 in crystal
[0x564dd8f4ef65] *Hash(String, Crystal::MetaTypeVar) +309 in crystal
[0x564dd8f4ee21] *Hash(String, Crystal::MetaTypeVar) +17 in crystal
[0x564dd8f4edf0] *Hash(String, Crystal::MetaTypeVar) +64 in crystal
[0x564dd896b521] *Crystal::NamedType+ +289 in crystal
[0x564dd9459841] *Crystal::RecursiveStructChecker#check_recursive_instance_var_container<Crystal::NamedType+, Crystal::NamedType+, Set(Crystal::Type+), Array(Crystal::Type+ | Crystal::Var+)>:Bool +81 in crystal
[0x564dd9459591] *Crystal::RecursiveStructChecker#check_single<Crystal::NamedType+>:Nil +161 in crystal
[0x564dd945f614] *Crystal::RecursiveStructChecker#check_types<Crystal::NamedType+>:Nil +500 in crystal
[0x564dd945964c] *Crystal::RecursiveStructChecker#check_single<Crystal::NamedType+>:Nil +348 in crystal
[0x564dd94594b3] *Crystal::RecursiveStructChecker#check_types<Crystal::Program>:Nil +419 in crystal
[0x564dd945918d] *Crystal::RecursiveStructChecker#run:Nil +29 in crystal
[0x564dd85995c3] *Crystal::Program#semantic:main_visitor<Crystal::ASTNode+, Crystal::MainVisitor+>:Crystal::ASTNode+ +2259 in crystal
[0x564dd97bf957] *Crystal::Repl#interpret<Crystal::Call>:Crystal::Repl::Value +71 in crystal
[0x564dd97bf8e7] *Crystal::Repl#interpret_exit:Crystal::Repl::Value +39 in crystal
[0x564dd97be3da] *Crystal::Repl#run:Nil +426 in crystal
[0x564dd96faf87] *Crystal::Command#repl:(Crystal::Repl::Value | Nil) +71 in crystal
[0x564dd96f5096] *Crystal::Command#run:(Bool | Crystal::Repl::Value | Nil) +1414 in crystal
[0x564dd96f498c] *Crystal::Command::run<Array(String)>:(Bool | Crystal::Repl::Value | Nil) +44 in crystal
[0x564dd96f48fe] *Crystal::Command::run:(Bool | Crystal::Repl::Value | Nil) +46 in crystal
[0x564dd8309b7c] __crystal_main +2668 in crystal
[0x564dd8510355] *Crystal::main_user_code<Int32, Pointer(Pointer(UInt8))>:Nil +37 in crystal
[0x564dd8510289] *Crystal::main<Int32, Pointer(Pointer(UInt8))>:Int32 +41 in crystal
[0x564dd83171b6] main +6 in crystal
[0x7fd81266f290] ?? +140565998400144 in /usr/lib/libc.so.6
[0x7fd81266f34a] __libc_start_main +138 in /usr/lib/libc.so.6
[0x564dd8309035] _start +37 in crystal
[0x0] ???

╰─ $ 11  cry version
Crystal 1.5.0-dev [0123976d8] (2022-06-09)

LLVM: 13.0.1
Default target: x86_64-pc-linux-gnu

Above backtrace get output when i quit from crystal i with C-d.

I have no problem
os:ubuntu 20
crystal:
Using compiled compiler at /home/w/Downloads/chromeDownload/crystal-master/.build/crystal
Crystal 1.5.0-dev (2022-06-21)

LLVM: 10.0.0
Default target: x86_64-pc-linux-gnu

w@w-F117-V:~/Documents/localgitserver/autoCheckVulns/svn/adad$ /home/w/Downloads/chromeDownload/crystal-master/bin/crystal i  hell.cr
Using compiled compiler at /home/w/Downloads/chromeDownload/crystal-master/.build/crystal
From: hell.cr:10:6 <Program>#hell.cr:

     5: end
     6:
     7: t=Time.local
     8: debugger
     9:
 => 10: data(12313)
    11: print t

pry> t.to_s
"2022-06-24 17:27:00 +08:00"
pry> exit

@acodervic not raise exception as me when run Time.local in REPL
We are compile use different version llvm, that is the reason cause this?

It works for me too on Ubuntu 20.04
$ ./bin/crystal -v
Using compiled compiler at .build/crystal
Crystal 1.5.0-dev [ff55fb1bb] (2022-06-22)

LLVM: 10.0.0
Default target: x86_64-pc-linux-gnu
$ ./bin/crystal i
Using compiled compiler at .build/crystal
icr:1:0> Time.local
=> 2022-06-25 05:38:50.505584349 +00:00

I rerun following code again after i update to 1.5.0dev.
Crystal 1.5.0-dev [ff55fb1bb] (2022-06-22)

LLVM: 13.0.1
Default target: x86_64-pc-linux-gnu

I still can reproduce ffi error on my local arch linux laptop.
 ╰─ $ 137  cry i
icr:1:0> Time.local
=> 2022-06-26 16:22:30.373334984 +08:00 Asia/Shanghai
icr:2:0> Invalid memory access (signal 11) at address 0x43
[0x559ce8fab986] *Exception::CallStack::print_backtrace:Nil +118 in crystal
[0x559ce8f820a6] ~procProc(Int32, Pointer(LibC::SiginfoT), Pointer(Void), Nil) +310 in crystal
[0x7faf81e3e8e0] ?? +140391775201504 in /usr/lib/libc.so.6
[0x559ce9dc8e17] *Crystal::Repl::Context::ffi_closure_fun<Pointer(Crystal::LibFFI::Cif), Pointer(Void), Pointer(Pointer(Void)), Pointer(Void)>:Pointer(UInt8) +55 in crystal
[0x559ce8f96736] ~procProc(Pointer(Crystal::LibFFI::Cif), Pointer(Void), Pointer(Pointer(Void)), Pointer(Void), Nil) +6 in crystal
[0x7faf825a20fb] ?? +140391782949115 in /usr/lib/libffi.so.8
[0x7faf825a2758] ?? +140391782950744 in /usr/lib/libffi.so.8
[0x559cea3a4eae] GC_invoke_finalizers +158 in crystal
[0x559cea3a4ffe] GC_notify_or_invoke_finalizers +174 in crystal
[0x559cea3a6f26] GC_generic_malloc_many +150 in crystal
[0x559cea3b3c1e] GC_malloc_kind +190 in crystal
[0x559ce90707c6] *GC::malloc<UInt64>:Pointer(Void) +6 in crystal
[0x559ce8f61a1e] __crystal_malloc64 +14 in crystal
[0x559ce93f1dad] *Crystal::Path::new<Array(String), Bool>:Crystal::Path +29 in crystal
[0x559ce93f73c4] *Crystal::Path::new<String, Bool>:Crystal::Path +84 in crystal
[0x559ce93f735f] *Crystal::Path::new<String>:Crystal::Path +31 in crystal
[0x559ce9fdd7eb] *Crystal::AbstractDefChecker#free_var_nodes<Crystal::Def+>:(Hash(String, Crystal::ASTNode+ | Crystal::Type+) | Nil) +251 in crystal
[0x559ce9fde50c] *Crystal::AbstractDefChecker#implements?<Crystal::Type+, Crystal::Type+, Crystal::Def+, Crystal::NamedType+, (Hash(String, Crystal::ASTNode+ | Crystal::Type+) | Nil)>:Bool +988 in crystal
[0x559ce9fdde3d] *Crystal::AbstractDefChecker#implements_with_ancestors?<Crystal::Type+, Crystal::Def+, Crystal::NamedType+, (Hash(String, Crystal::ASTNode+ | Crystal::Type+) | Nil)>:Bool +77 in crystal
[0x559ce9fdda7c] *Crystal::AbstractDefChecker#check_implemented_in_subtypes<Crystal::NamedType+, Crystal::NamedType+, Crystal::Def+, (Hash(String, Crystal::ASTNode+ | Crystal::Type+) | Nil)>:Nil +476 in crystal
[0x559ce9fdd892] *Crystal::AbstractDefChecker#check_implemented_in_subtypes<Crystal::NamedType+, Crystal::Def+, (Hash(String, Crystal::ASTNode+ | Crystal::Type+) | Nil)>:Nil +18 in crystal
[0x559ce9fdd678] *Crystal::AbstractDefChecker#check_single<Crystal::NamedType+>:Nil +1176 in crystal
[0x559ce9fdd1a1] *Crystal::AbstractDefChecker#check_types<Crystal::Program>:Nil +417 in crystal
[0x559ce9fdce8a] *Crystal::AbstractDefChecker#run:Nil +26 in crystal
[0x559ce91b01ba] *Crystal::Program#top_level_semantic<Crystal::ASTNode+>:Tuple(Crystal::ASTNode+, Crystal::TypeDeclarationProcessor) +2282 in crystal
[0x559ce91cf799] *Crystal::Program#semantic:main_visitor<Crystal::ASTNode+, Crystal::MainVisitor+>:Crystal::ASTNode+ +73 in crystal
[0x559cea361cfa] *Crystal::Repl#interpret<Crystal::Call>:Crystal::Repl::Value +74 in crystal
[0x559cea361c87] *Crystal::Repl#interpret_exit:Crystal::Repl::Value +39 in crystal
[0x559cea360831] *Crystal::Repl#run:Nil +417 in crystal
[0x559cea2a593a] *Crystal::Command#repl:(Crystal::Repl::Value | Nil) +74 in crystal
[0x559cea2a06f1] *Crystal::Command#run:(Bool | Crystal::Repl::Value | Nil) +1409 in crystal
[0x559cea29fffb] *Crystal::Command::run<Array(String)>:(Bool | Crystal::Repl::Value | Nil) +43 in crystal
[0x559cea29ff6e] *Crystal::Command::run:(Bool | Crystal::Repl::Value | Nil) +46 in crystal
[0x559ce8f61958] __crystal_main +2536 in crystal
[0x559ce914c163] *Crystal::main_user_code<Int32, Pointer(Pointer(UInt8))>:Nil +19 in crystal
[0x559ce914c0b9] *Crystal::main<Int32, Pointer(Pointer(UInt8))>:Int32 +41 in crystal
[0x559ce8f6ed46] main +6 in crystal
[0x7faf81e29290] ?? +140391775113872 in /usr/lib/libc.so.6
[0x7faf81e2934a] __libc_start_main +138 in /usr/lib/libc.so.6
[0x559ce8f60e95] _start +37 in crystal
[0x0] ???

I can reproduce this Time.local error on Ubuntu 22.04 with LLVM 13 or LLVM14.
$ cr -v
Using compiled compiler at /home/chao/git/personal/crystal/.build/crystal
Crystal 1.5.0-dev [b2dc03a48] (2022-07-03)

LLVM: 13.0.1
Default target: x86_64-pc-linux-gnu

OS: Ubuntu 22.04

It seems like there's something wrong with LLVM 13 or other newer libraries on Ubuntu 22.04.
The interpreter is completely broken on Ubuntu 22.04 with LLVM 13 or LLVM 14 for me, it segfaults immediately.
For now, I'm sticking with Ubuntu 20.4 and LLVM 10. It's not a big deal for me since I use vscode devcontainer to switch between OS distributions, but it's bad for others developing on incompatible distributions such as Arch.

What happens if you run the interpreter with GC_DONT_GC=1 env var? If that doesn't crash it's probable that I forgot to track things correctly

Setting GC_DONT_GC=1 fixed the Time.local issue.
But the Lucky toy app still segfaults even with this flag on.
Kemal hello world app works without flag.
Grip hello world app segfaults without the flag and works fine with the flag.
So it seems like this flag fixes part of the problem.

@asterite @straight-shoota I think I found the cause of the segfault problem on Ubuntu 22.04.
Ubuntu 22.04 uses libffi8 while Ubuntu 20.04 uses libffi7 for the libffi-dev package.
Ubuntu 22.04:
$ apt show libffi-dev
Package: libffi-dev
Version: 3.4.2-4
Priority: extra
Section: libdevel
Source: libffi
Origin: Ubuntu
Maintainer: Ubuntu Developers<EMAIL_ADDRESS>Original-Maintainer: Debian GCC Maintainers<EMAIL_ADDRESS>Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 336 kB
Depends: libffi8 (= 3.4.2-4)
Conflicts: libffi4-dev
Homepage: https://sourceware.org/libffi/
Download-Size: 63.7 kB
APT-Sources: http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
Description: Foreign Function Interface library (development files)

Ubuntu 20.04:
root@e08a4d3764e9:/# apt show libffi-dev
Package: libffi-dev
Version: 3.3-4
Priority: extra
Section: libdevel
Source: libffi
Origin: Ubuntu
Maintainer: Ubuntu Developers<EMAIL_ADDRESS>Original-Maintainer: Debian GCC Maintainers<EMAIL_ADDRESS>Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 312 kB
Depends: libffi7 (= 3.3-4)
Conflicts: libffi4-dev
Homepage: https://sourceware.org/libffi/
Download-Size: 57.0 kB
APT-Sources: http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
Description: Foreign Function Interface library (development files)

Install the libffi7 and corresponding libffi-dev on Ubuntu 22.04 fixes the issue.
This causes ld warning though: /usr/bin/ld: warning: libffi.so.8, needed by /usr/lib/llvm-13/lib/libLLVM-13.so, may conflict with libffi.so.7
I guess the current libffi crystal binding only works with libffi7 and doesn't support libffi8. There must be some interface changes between 7 and 8 for libffi.

I guess the current libffi crystal binding only works with libffi7 and doesn't support libffi8. There must be some interface changes between 7 and 8 for libffi.

Yes, i  can confirm this in my arch laptop.
 ╰─ $ pacman -Ql libffi |grep /usr/lib
libffi /usr/lib/
libffi /usr/lib/libffi.so
libffi /usr/lib/libffi.so.8
libffi /usr/lib/libffi.so.8.1.0
libffi /usr/lib/pkgconfig/
libffi /usr/lib/pkgconfig/libffi.pc

arch often broken somethings because it too new, maybe i should switch back to use Slackware.

@cyangle thanks for digging into this!
From the list of changes between these versions, https://github.com/libffi/libffi/pull/540 looks like a very strong candidate. The memory layout of LibFFI::Closure has changed between 3.3 and 3.4 (which equates to libffi7 and libffi8 packages).
When linking against libffi 3.4 the constant FFI_TRAMPOLINE_SIZE is 32 instead of 24 (16 instead of 12 on 32-bit).

Check #12192. It should resolve this issue.

Confirm! it fix the the issue https://github.com/crystal-lang/crystal/issues/11802#issuecomment-1166453378, Good Job!


Docker@2 reports target as unexpected property

Consider a pipeline definition snippet like:
jobs:
- job:
  container:
    image: mycontainer
    endpoint: container-reg
  steps:
  - task: Docker@2
    target: host
    inputs:
      command: build

The default tasks running in the job are to run in container mycontainer, but there are Docker@2 tasks that need to run on the host. The VS Code extension lists target as an unexpected property in the problems. Running the pipeline behaves as expected: the container build task is executed on the agent host.

Thanks for reporting @brsmyth. Looks like this is an issue with the YAML schema we're getting back from ADO. I'll file an issue on them and link to it here when I do.
Documentation on the target property for reference: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/tasks?view=azure-devops&tabs=yaml#step-target

The same yaml schema has another error, which is that the command: pull raises this error even though "pull" is a valid value:

Value is not accepted. Valid values: "buildAndPush", "build", "push", "login", "logout", "start", "stop".

@jdthorpe Would you mind creating a new issue for that? I believe it should be easier to fix than this one :).

I'll file an issue on them and link to it here when I do.

Filed as https://developercommunity2.visualstudio.com/t/YAML-Schema-API-is-missing-target-proper/10085540.