你这个排查过程搞复杂了

你先在中间加一个数据交换的逻辑，让这两个函数不要直接碰面

经验判断，大概率是因为错误使用了某个函数导致的

【 在 flingfish 的大作中提到: 】
: Linux下的C语言编程，glibc版本是glibc_2.31-13+deb11u5.debian
: 程序逻辑大概是这样的，从一个文件A里用getline()逐行读取，然后对每行进行字符串解析并且做相应的业务逻辑。问题是每次读到一个特定的行，getline返回的数据就会乱掉。用GDB调试之后，发现是getline把当前行的一部分，和之前已经读过的某一行拼在一起返回了。getline()是buffered io，它自己维护一个用户态buffer，先把数据从内核读到自己的用户态buffer，再把buffer里的数据copy到一块malloc出来的内存里返回给调用者。这个用户态buffer满了之后，getline（）函数是要再重新读数据填buffer，并且更新相应的指针。但是GDB跟踪发现在出问题的这一行，读到buffer末尾还没找到一个\n，getline()执行重新读数据填buffer的操作，但是执行完毕的结果是指针回到了buffer头，但是buffer里的数据还是旧的。于是之前读过的某一行就这样被拼到了这一行的后面。
: 关掉业务逻辑，发现简单的getline逐行读取没有这个问题，由此可以断定是某业务代码破坏了getline的执行逻辑。经过缩小范围，发现是调用的某个第三方函数引起的问题。这个函数我没有源码，从注释上看这个函数的功能是dump某些数据到另外一个文件B里面。我怀疑这个函数在dump的过程中做了某种多进程/多线程的操作，或者对文件A的内核buffer产生了某种影响。
: ...................
--
FROM 111.33.206.*

我理解，你需要先知道哪里错了，写了个什么数据过去

然后才能去分析这个错误为什么会导致库异常行为

你上去就gdb标准库，这是选了一条最难的路

【 在 flingfish 的大作中提到: 】
: 如果是这么简单的问题，不值得我用GDB苦哈哈的单步跟libc
--
FROM 223.104.41.*