高山linux上的程序段错误.我该如何解决? [英] Program segfaults on alpine linux. How do I resolve it?

问题描述

我一直在使用C/C ++和主叫人的范围.我什至在函数调用之前插入了printf("Argument is %p", agent);，它会打印出内存，并且可以确认它不为null.从反汇编中，看起来像这样的行:将代理的内容(0x557a1d20)复制为被调用方堆栈中的本地变量会导致段错误.即使在make clean和重新编译之后，段错误始终会在此时发生.激活记录失败?堆栈损坏?

更新:我制作了一个更轻巧的容器并运行了它，现在它在同一个priv_conn_keepalive_tick_unlocked中的其他位置进行段错误处理.该参数似乎已设置(请注意0x7ffff7f9ad08):

因为我以为我可能会碰到 libmusl的默认的堆栈限制为80k，我使用getrlimit(RLIMIT_STACK, &rl)来获取堆栈大小，看起来已经是8 MB，而不是80k.进一步增加此限制似乎没有任何区别，除了如果我分配的内存超过8 MB，我的程序会在内部 Gdb早期崩溃. Gdb表示收到未知信号??"；在gdb外部，它会在正常情况下崩溃，而正常情况下该崩溃通常是在未更改堆栈大小的情况下进行的.

我不确定问题到底是什么(堆栈损坏?)以及下一步该如何解决.

这是我程序的流程:

对于创建的每个对等节点，将使用fork()创建一个子进程.父级<->子级通信由ZeroMQ完成，我使用协议缓冲区将在子级内部触发的所有回调(及其回调)转发到在父级进程中运行的事件循环中.

因此，对于上述程序，有2个子进程和1个父进程.

复制步骤:

• 源文件: https://github.com/hamon-in/librtcdcpp/blob/alpine-test/examples/websocket_client/2in1.c
• 高山docker容器: https://github.com /hamon-in/librtcdcpp/blob/alpine-test/Dockerfile.amd64
• 运行容器，二进制文件位于/psl-librtcdcpp/examples/websocket_client/2in1
• 2in1将产生两个子进程，这两个子进程都将崩溃.

解决方案

在进一步研究中，崩溃发生在一条指令中，该指令与栈基指针的负偏移量相差较大，因此可能只是一次简单的栈溢出. /p>

解决此问题的正确方法是减少过多的堆栈使用量或在pthread_create时显式请求大堆栈，但是我看不到从何处调用pthread_create.快速检查以确认这是问题所在，可以通过在程序的早期位置执行以下操作来覆盖新线程的默认堆栈大小:

pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setstacksize(&attr, 1<<20); // 1 MB
pthread_setattr_default_np(&attr);

I've been working on a webrtc datachannel library in C/C++ and wrote a program in C to:

1. Create two peers from the same process.
2. Establish a connection between them.
3. Close the connection if it's successful.

Everything runs fine on a debian docker container and on my host opensuse tumbleweed (all x86_64 and 64bit), but on alpine linux container (64bit x86_64), I'm getting a SEGFAULT inside the child processes:

The function above is from the program's dependency "libnice". It seems like *agent == NULL and there is no way that is made null in the caller's scope. I even inserted a printf("Argument is %p", agent); right before the function call and it prints out its memory and I can verify it's not null. From the disassembly, it looks like the line where copying the agent's contents (0x557a1d20) as the local variable in the callee's stack results in a segfault. The segfault always occurs at this point even after a make clean and recompilation. Fail at activation record? Stack corruption?

UPDATE: I made a more lightweight container and ran it, and now it segfaults at a different place in that same priv_conn_keepalive_tick_unlocked. The argument seems to be set though (Notice the 0x7ffff7f9ad08):

Since I thought I might be hitting the libmusl's default stack limit of 80k, I used getrlimit(RLIMIT_STACK, &rl) to obtain the stack size and it looks like it's already 8 MB and not 80k. Increasing this limit further does not seem to make any difference except that if I assign more than 8 MB, my program crashes early inside the Gdb. Gdb says it got an unknown signal "? ?"; outside the gdb, it crashes at the normal point where it normally crashes without the altered stack size.

I'm not sure what exactly the problem is (stack corruption?) and what to do next to resolve this.

Here's my program's flow:

For every peer that is created, a child process is created with a fork(). Parent <--> child communication is done by ZeroMQ and I use protocol buffers to forward any callbacks (and its arguments) that are triggered inside the child onto an event loop running in the parent process.

So for the above program, there are 2 child processes and 1 parent process.

Steps to reproduce:

• Source file: https://github.com/hamon-in/librtcdcpp/blob/alpine-test/examples/websocket_client/2in1.c
• Alpine docker container: https://github.com/hamon-in/librtcdcpp/blob/alpine-test/Dockerfile.amd64
• Run the container and binary is located at /psl-librtcdcpp/examples/websocket_client/2in1
• 2in1 will spawn two child processes both of which will crash.

解决方案

On further investigation, the crash is in an instruction writing at a mildly large negative offset from the stack base pointer, so it's probably just a simple stack overflow.

The right way to fix this is reducing the excess stack usage or explicitly requesting a large stack at pthread_create time, but I don't see where pthread_create is being called from. A quick check to verify that this is the problem would be to override the default stack size for new threads by performing the following somewhere early in the program:

pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setstacksize(&attr, 1<<20); // 1 MB
pthread_setattr_default_np(&attr);

这篇关于高山linux上的程序段错误.我该如何解决?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！