在一个EXE应用程序中调用多个由.NET9 AOT发布的动态库so文件会引发异常 #114193
Comments
ghost
added
the
dotnet-policy-service
bot
added
the
untriaged
|
|
|
Can you post a repro project or more complete steps? Screenshots will not be sufficient to reproduce and diagnose the problem. |
agocke
added
the
needs-author-action
|
我做了一个示例程序, 并且写了复现步骤, 请参阅: |
dotnet-policy-service
bot
removed
the
needs-author-action
|
Thanks! @MichalStrehovsky can you take a look and see if this is a known issue? |
|
我目前在网上没收到相关的问题, 也没找到相关的解决方案。我不能确定是否是已知的问题。我能确定的是我网络上针对该问题没有搜到, 然后使用AI搜索得到可能是NativeAOT-coreclr相关的问题, 所以我才来此请教的。 |
|
I tried to repro this on linux-x64 and linux-arm64 but couldn't with .NET 9. Does this happen for you just with .NET 8, or .NET 9 as well? |
|
我在.NET8 和 .NET9 中都存在这个问题 |
|
@527395632 could you please
|
|
Try running your a.out under and paste the output? (It might have more information about why this is failing.)strace |
I meant running |
|
下面是我使用strace输出的日志信息： execve("./a.out", ["./a.out"], 0x7fcb88b3c0 /* 52 vars /) = 0 |
|
The relevant line in the log is: This is the same issue as #96592. The system doesn't allow the GC reserving 256 GB of address space twice. The |
|
Tagging subscribers to this area: @dotnet/gc |
|
非常抱歉, 是我之前环境变量设置错了, 经过我重新测试及参考 #96592 的问题, 已经成功解决问题了。 在此, 非常感谢 @MichalStrehovsky @agocke @jkotas @frankbolero 的支持, 谢谢你们!
|
|
can you try setting DOTNET_GCRegionRange to something like 8GB and check if that works better? |
|
我对DOTNET_GCRegionRange 不是很了解。我尝试咨询了AI, 得到以下回复： |
|
(configuration system considers 0x optional, but 0x makes it clear that these settings require hexadecimal values) |
|
export DOTNET_GCRegionRange=0x200000000 经过测试我得出以下结论：
|
I'm not sure about this. using System;
using System.Runtime;
using System.Runtime.InteropServices;
GCMemoryInfo memoryInfo = GC.GetGCMemoryInfo();
Console.WriteLine($"HighMemoryLoadThresholdBytes: {memoryInfo.HighMemoryLoadThresholdBytes}");
Console.WriteLine($"MemoryLoadBytes: {memoryInfo.MemoryLoadBytes}");
Console.WriteLine($"TotalAvailableMemoryBytes: {memoryInfo.TotalAvailableMemoryBytes}");
Console.WriteLine($"GC Heap Hard Limit (approx): {memoryInfo.TotalAvailableMemoryBytes / (1024 * 1024)} MB");
does produce the same result for me (which is different than without setting the env var). |
|
哈哈哈哈, 那看来可以结案拉! 非常感谢大家的帮助!! |
|
using "0x" or not should produce the same result as @am11 observed. if this is not the case you are seeing, something is wrong. this is documented in our config page https://learn.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector -
|
|
#114944 will make this easy to diagnose. |
It might help for others, but probably not for this case. This case is for a shared library built with native AOT and the user trying to load two such shared libraries into the process (each initializing their own GC). As far as the consumer of the shared library built with native AOT is concerned, these are just native libraries like any other (they just expose a couple C-ABI exports). There's no "host" involved. We don't have a way to communicate this to the user, so it will stay a fail fast. See the repro above for details. The "host" is the C code that just dlopens a library and calls a symbol in it. Is there really no way for GC to figure out the reservation is going to fail and adjust accordingly? These are pretty expensive for us to root cause. |
|
@MichalStrehovsky 说的非常正确。 应用场景确实如此。 谷歌翻译: (https://translate.google.com/?hl=zh-cn&sl=zh-CN&tl=en&op=translate) |
|
Closing this one as resolved for now -- but we can open up a new issue for diagnostic improvements |
Description
在一个EXE应用程序中调用多个由.NET9 AOT发布的动态库so文件会引发异常
Reproduction Steps
AOT编译命令：
C语言调用代码：
调用结果：
Expected behavior
在一个EXE中应该是允许调用多个由.NET AOT编译的动态库的
Actual behavior
在一个EXE中应该是允许调用多个由.NET AOT编译的动态库时会报错, 导致程序闪退
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: