未明信号:使用.net核心云时的11次修复

Question

我已经用Cloud创建了两个.net核心3.0 C#服务。当我试图插入一个防火墙文档时，应用程序就会在云中崩溃。在本地，它与相同的防火墙连接一起工作。昨天有一项服务运作得很好。我能做些什么来调试这个问题？

提供的C#代码显示

暗号: 11，pid=1，tid=13，fault_addr=453942。

在云日志中作为错误消息运行。坠机发生在documentRef.SetAsync(plan);线路上。未亮信号11听起来像是分段故障。

这些服务使用nuget包(1.0.0)和Grpc.Core (1.22.1)。

[FirestoreData]
public class Plan
{
        [FirestoreProperty]
        public string PlanId{ get; set; }
}

[...]

using Google.Cloud.Firestore;

[...]

var plan = new Plan() { PlanId = "testId"};
Database = FirestoreDb.Create("testing-profile-crawler");
var documentRef = Database.Collection("crawler-plan").Document("test");
documentRef.SetAsync(plan);

Answer 1

2019年11月的答案适用于高山3.9，但3.10或3.11不适用。

有一个新gRPC问题对此进行了介绍，但我确实成功地降低了libc6-compat的评级，如本文所示：

RUN echo 'http://dl-cdn.alpinelinux.org/alpine/v3.8/main' >> /etc/apk/repositories && \
    apk update --no-cache && \
    apk add --no-cache bash libc6-compat=1.1.19-r11

显然，降低库版本的级别是一件非常激烈的事情--因此值得进行彻底的测试。但它至少适用于测试应用程序，因此可能对任何遇到同样问题的人都有帮助。

Answer 2

这个问题并不是.NET核心特有的-它实际上是关于在高山上运行gRPC。gRPC本机库(由Grpc.Core使用)是针对glibc构建的，默认情况下，glibc不存在于高山上。

gRPC团队对此有一个解决办法，包含在他们的测试构建中，使用为阿尔卑斯山建造的glibc版本。我只能说它在我的测试中起了作用。这很可能与阿尔卑斯山上的gRPC一样接近“支持”，目前可能也是如此。

我使用的Dockerfile开始如下所示：

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0.0-alpine3.9

RUN apk update && apk --no-cache add ca-certificates wget
RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.30-r0/glibc-2.30-r0.apk
RUN apk add glibc-2.30-r0.apk

..。没有安装libc6-compat或符号链接步骤。在此之后，您应该能够像以前一样使用其余的Dockerfile。注意，这使用了Alpin3.9--当我尝试时，3.0.0-alpine的标记没有工作。

有了gRPC在.NET Core3.0中的支持，当我们拥有将我们的库升级到Grpc.Core 2.x时，您就可以使用微软gRPC客户端库来代替.但是，Grpc.Core的某些方面目前还不受支持，我不希望我们能够让使用微软版本变得非常容易(尽管我们确实想尝试)。