Question

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

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

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

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

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”，由空指针终止。

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

此外，由于没有释放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说：无效读取大小1在0x40A5685：vfprintf（vfprintf.c：1655）由0x40AA7FE：printf（printf.c：34）由0x4075904 :(低于主要）（libc-start.c：260）地址0x42121af是1个字节之前大小为17的块在0x40299D8处分配：malloc（在/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so中）由0x804887D：toHex（weird.c：107）由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的结果以检查它是否实际返回了您在测试用例中的预期。

Answer 2

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

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

2 个答案: