两个 printfs 以不同的方式打印相同的字符串

Question

我正在尝试创建一个处理大整数运算的库。大整数存储在结构中：

typedef struct BigInt BigInt;
struct BigInt
{
    uint32_t size;
    uint32_t *data;
};

第一个成员是包含数字长度的uint32_t，第二个成员是指向实际数字数据（存储在二进制补码中）的指针。我写了一个简单的 toHex(BigInt *a) 函数，它分配内存，将大整数的十六进制值打印到字符串，以及 returns 地址。

在我的主循环中，我有以下内容：

int main(int argc, char *argv[])
{
    char *ap, *bp;
    BigInt *a = fromUInt32(0x7fffffff), *b = fromUInt32(1), *c = fromUInt32(0x80000000);
    _add(a, b);
    ap = toHex(a);
    bp = toHex(c);
    printf("%s\n", ap);
    printf("%s\n%s\n", ap, bp);
    printf("%s\n%s\n", ap, bp);
    free(ap);
    free(bp);
    deleteBigInt(a);
    deleteBigInt(b);
    deleteBigInt(c);
}

奇怪的是，它打印了

0000000080000000
0
0000000080000000
0000000080000000
0000000080000000

因此第二个 printf 语句为 ap 打印的内容与第一个和第三个 printf 语句不同。看起来第一个 printf 语句是正确的，第二个是搞砸了。我已经使用 GDB 单步执行我的代码，在对 toHex 求值后，ap 指向字符串“0000000080000000”，以空指针终止。

我完全莫名其妙。据我所知，可能性是：
1. 由于某些奇怪的原因，我运行陷入未定义的行为。
2. 在_add中我调用了一个用x86汇编代码编写的例程，其中可能有错误（但我通过保留esi、edi、ebx、ebp和esp来遵守GCC的调用约定）。
3. printf有一个bug，貌似不太可能。

我也有一个明显的"memory leak"（引用是因为关于内存泄漏到底是什么的观点似乎不同）不释放 toHex 分配的内存，但这应该无关紧要。

Sourav Ghosh 请求我的 toHex 函数，如下：

char numToHex[] = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' };
char *toHex(BigInt *a)
{
    char *result, *ptr;
    // allocate enough space for 8 characters for each uint32_t and 1 terminating 0
    ptr = result = malloc(a->size * 8 + 1);
    // loop over the uint32_t's stored in a->data
    // (there are a->size of them)
    for (uint32_t i = 0; i < a->size; i++)
        // parse 8 blocks of 4 bits
        for (uint32_t j = 0; j < 8; j++)
            // grab the right bits and convert them to a hex digit
            *(ptr++) = numToHex[(a->data[i] >> ((7 - j) * 4)) & 0xf];
    // add a terminating zero byte
    *ptr = 0;
    return result;
}

我已经在 ~100 lines of C + ~70 lines of assembly 的程序中隔离了这种奇怪的行为。编译可以用

完成

nasm -f elf -s <AssemblyName>.asm
gcc <CFile>.c <AssemblyName>.o -o <OutputProgram> -m32 -std=c99 -g

代码未注释，适用于想要自己检查行为的人。

编辑：Jan Spurny 和 Matt McNabb 敦促我使用 Valgrind。 Valgrind 说： 0x40A5685 处大小 1 的无效读取：vfprintf (vfprintf.c:1655) by 0x40AA7FE: printf (printf.c:34) by 0x4075904: (below main) (libc-start.c:260) 地址0x42121af 是在 0x40299D8 处分配的大小为 17 的块之前的 1 个字节：malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) by 0x804887D: toHex (weird.c:107) by 0x8048565: main (weird.c :30)

但这没有意义，因为我在 toHex 中将结果设置为 malloc，之后没有任何改变。我现在敢打赌，某些寄存器在汇编函数中被破坏了。 Edit2：检查 GDB 后，我可以看到没有寄存器损坏。我还是一头雾水

Answer 1

reduce函数有一个错误：

while (i < a->size && !(a->data[i])) i++;
if (a->data[i] & SIGNBIT) i--;

如果满足 i < a->size 条件，则 a->data[i] 访问越界，导致未定义的行为。 reduce的另一个分支也有同样的问题

_add 函数中存在一个错误（尽管在您的测试用例中未触发）：

void *k = realloc(a->data, b->size * 4);
memmove((void *)(a->data + displacement), (void *)a->data, a->size * 4);
// ....other code using `a->data`

在 realloc 之后，a->data 变得不确定，因此使用它会导致未定义的行为。这可以解释您的症状，因为未来的分配可能会重新使用 a->data 仍指向的相同释放块。

也许您还想在这之后添加一行 a->data = k;？

为了在调试代码时获得良好的帮助，如果您可以执行以下操作，那就太好了：

检查所有 *alloc 系列函数的结果，如果返回 NULL 则退出。否则你会得到未定义的行为（期望段错误是不可靠的）。
用 C 重写汇编函数。出于多种原因（调试、代码可移植性、优化），这是一个好主意。甚至可能会发现 gcc -O3 生成的代码比您的手写版本更快；这就是编译器擅长的。
检查调用 newAddress 的结果以实际检查它 returns 您在测试用例中所期望的结果。

Answer 2

我在 forum.osdev.org 上做了 a thread（那里有一些非常聪明的人），jnc100 通知我 ABI 期望在调用函数时清除方向标志。我在汇编程序中设置了方向标志（在_add中调用），果然在汇编程序中清除就解决了问题。

两个 printfs 以不同的方式打印相同的字符串

Two printfs print the same string differently

c

linux

gcc

pointers

i386