段错误 (核心已转储)

[FTS427]

❗ 检查表

• 搜索了已有的 issues 列表中是否有相似问题
• 查看 Releases 中最新版是否已修复你所遇到的问题
• 查看 Actions 中最新Dev版是否已修复你所遇到的问题

问题描述

无法启动（和之前的那个旧版的WonderLab一个问题。。。）

日志

小蓝瓶错误报告-System.InvalidOperationException.txt

问题复现率

必现

复现步骤

参考：
Blessing-Studio/WonderLab#70

操作系统版本

Linux

WonderLab版本

1.2.5

插件信息

No response

补充信息

参考：
Blessing-Studio/WonderLab#70
（MATRIX-feather说的这个解决方案好像不行）

[YangSpring114]

字体的问题，在想办法了

[FTS427]

字体的问题，在想办法了

好的，加油！

[FTS427]

将将～ 崭新错误！

segmentation fault (core dumped)  ./wonderlab

[FTS427]

将将～ 崭新错误！

segmentation fault (core dumped)  ./wonderlab

不算是解决方案的方案：

ulimit -c 2048
ulimit -c unlimited
sudo -i
cd /*WonderLab所在的的文件夹位置*
./wonderlab

注意：在每一次启动前要删除形如“wonderlab.xxxx”的文件（“xxxx”是随机的四个不一样的数字），否则下一次无法运行

[ruattd]

@FTS427 这个问题你得找巨硬，dotnet跨平台的问题

[YangSpring114]

@FTS427 这个问题你得找巨硬，dotnet跨平台的问题

有没有一种可能，这是avalonia底层的问题

[ruattd]

有没有一种可能，这是avalonia底层的问题

Avalonia连可执行文件也包管了？这不是dotnet负责的东西吗

[FTS427]

@FTS427 这个问题你得找巨硬，dotnet跨平台的问题

有没有一种可能，这是avalonia底层的问题

啊啊啊，你干嘛嗨嗨呦～

[FTS427]

网上有一种说法是因为程序自身的内存分配或者指针错乱导致的（我也不确定

[YangSpring114]

网上有一种说法是因为程序自身的内存分配或者指针错乱导致的（我也不确定

好像是

[ruattd]

网上有一种说法是因为程序自身的内存分配或者指针错乱导致的（我也不确定

segmentation fault 确实是指针满天飞

[memorydream]

在 avalonia 的讨论里看到这个问题，在那边回答过了，在这里用中文回答一下

这两个问题其实都是 skia 或者 skiasharp 的问题，当系统环境变量的 LC_CTYPE 不是 en_US.UTF-8 时，会出现找不到字体的异常，虽然我没有具体测试过，但这个问题至少会出现在中文和日文环境中

如果想使用系统字体的话，可以删掉 .With(new FontManagerOptions...)，只需要确认用户的环境变量值是 en_US.UTF-8 就可以了

最简单的方法是单独提供一个 launch.sh，在里面写 export LC_CTYPE=en_US.UTF-8 && wonderlab，确保在启动前设置 LC_CTYPE

这个也可以写在 desktop 文件里，一样的

补充一下，之所以会认为是 skia* 的问题，是因为在 Uno platform 这个 UI 框架中也存在同样的字体问题

[FTS427]

在 avalonia 的讨论里看到这个问题，在那边回答过了，在这里用中文回答一下

这两个问题其实都是 skia 或者 skiasharp 的问题，当系统环境变量的 LC_CTYPE 不是 en_US.UTF-8 时，会出现找不到字体的异常，虽然我没有具体测试过，但这个问题至少会出现在中文和日文环境中

如果想使用系统字体的话，可以删掉 .With(new FontManagerOptions...)，只需要确认用户的环境变量值是 en_US.UTF-8 就可以了

最简单的方法是单独提供一个 launch.sh，在里面写 export LC_CTYPE=en_US.UTF-8 && wonderlab，确保在启动前设置 LC_CTYPE

这个也可以写在 desktop 文件里，一样的

补充一下，之所以会认为是 skia* 的问题，是因为在 Uno platform 这个 UI 框架中也存在同样的字体问题

行，正在测试

[FTS427]

写一个"launch.sh",如下（写完用chmod u+x ./launch.sh赋予权限）

#! sh                                                                                                                         
export LC_CTYPE=en_US.UTF-8 && ./wonderlab

[github-actions]

你的议题已解决
感谢反馈
点击这里反馈新问题

[memorydream]

在这里再补充一些我知道的细节

这个问题在 macos 上似乎也存在（印象来自于 steam++ 的相关 issue 下的评论）
LC_CTYPE 是应用识别语言环境的依据，如果应用支持 i18n/l10n的话，可能会导致一些小问题——比如通过 CultureInfo.CurrentCulture 来确定系统语言，此时就只会返回 en-US，导致基于系统语言的自动多语言不准确

[YangSpring114]

在这里再补充一些我知道的细节

这个问题在 macOS 上似乎也存在（印象来自于 steam++ 的相关下的评论） 是应用识别语言环境的依据，如果应用支持 i18n/l10n的话，可能会导致一些小问题——比如通过 来确定系统语言，此时就只会返回 ，导致基于系统语言的自动多语言不准确LC_CTYPE``CultureInfo.CurrentCulture``en-US

感谢你的帮助，不过我们目前在多台架构不一样的机子上测试过了，并没有在 MacOS 上出现这种情况

[FTS427]

在 avalonia 的讨论里看到这个问题，在那边回答过了，在这里用中文回答一下

这两个问题其实都是 skia 或者 skiasharp 的问题，当系统环境变量的 LC_CTYPE 不是 en_US.UTF-8 时，会出现找不到字体的异常，虽然我没有具体测试过，但这个问题至少会出现在中文和日文环境中

如果想使用系统字体的话，可以删掉 .With(new FontManagerOptions...)，只需要确认用户的环境变量值是 en_US.UTF-8 就可以了

最简单的方法是单独提供一个 launch.sh，在里面写 export LC_CTYPE=en_US.UTF-8 && wonderlab，确保在启动前设置 LC_CTYPE

这个也可以写在 desktop 文件里，一样的

补充一下，之所以会认为是 skia* 的问题，是因为在 Uno platform 这个 UI 框架中也存在同样的字体问题
好，问题来了，如何改写desktop文件呢？

[memorydream]

好，问题来了，如何改写desktop文件呢？

我看仓库里确实提供了一个 .desktop 文件，修改它的 Exec

[FTS427]

已经修改成功，感谢