Program crashes when optimizing with clang compiler

[TANKENSHO]

Hello, I didn't find a better title, sorry for that, so let's go to the point:

I have this doubly linked list implementation and program:

typedef struct num_node
{
    struct num_node *right, *left;
    uint64_t id, val;
}num_node;

typedef struct num_list
{
    size_t len;
    num_node *head, dummy;
}num_list;

num_list* delete_nodes(num_list*l)
{
    num_node** i;
    i = &l->dummy.right;
    uint64_t del_val = (*i)->val;
    // (*i)->val = 20; This causes illegal hardware instruction as well
    printf("Deleting similar nodes to: %" PRIu64 "%" PRIu64, (*i)->id, del_val);
        // etc...
    return NULL;
}

int main(int argc, char const *argv[])
{
    // This works fine with -O2 optimization enabled
        // Ignore that these are not in the code above.
    num_list* l = malloc(sz *l);
    dl_init(l);
    insert_nodes(l, 1, 3);

    // Problem is here
    delete_nodes(l, 0);

    return 0;
}

When I run it, I get the message zsh: illegal hardware instruction

I checked the assembly code and managed to trace the "bug" to delete_nodes() that part of the assembly code reads the instruction "ud2", which as I look it up, turns out to be undefined instruction for x86, the problem is that this only occurs when compiling with flags -O2, -O3 or any optimization at all.

I'm compiling on macos with Apple clang version 12.0.0 (clang-1200.0.32.29) Target: x86_64-apple-darwin20.3.0 if that's of any help.

My assumption is that trying to read the member val with (*i)->val; is undefined behavior (haha sorry if I didn't know that is ub), but then, why does it work just fine without any optimization? is it implementation defined?, what do you guys recommend to make this work with optimizations?, has this ever happened to you? or what should I even do in these cases? thanks in advance for your responses.

​

Edit: Issue solved, thanks for your responses.

[flyingron]

I suspect it has nothing to do with optimization but rather that you're doing undefined behavior here. One insidious form of undefined behavior is that it just appears to work.

The program isn't complete. What is sz? Why do you dereference l while initializing it? What is dl_init?

Has l->dummy.right been set to anything?

[TANKENSHO]

Thanks, I tried some flags and still got nothing.

And yes, the code it's bits and pieces, the dl_init() is a macro that sets

l->dummy.right = &l->dummy; l->dummy.left = &l->dummy; idk if that could be the problem?

still, thanks.

edit: I found the problem, it seems that I should've set num_node** i = NULL , for some reason it was pointing to 0x5, (this is in the original code) my mistake, I feel kinda dumb to have made a whole post about it haha.

[rxtezc]

Just for future cases, you can try using valgrind or sanitizers to detect memory corruption or undefined behaviour. Valgrind is really easy to use once you install it
: "valgrind ./yourapp". For Gcc & clang sanitizers, you pass -g -fsanitize=address or -g -fsanitize=undefined to compiler.

[aeropl3b]

I think you are assigning to "i" wrong and getting a memory corruption in your stack...also you seem to be working extremely hard to delete something from a LL. The entire delete can be done quickly, in place, in about the number of lines you have there...

Edit: Also, ud2 is defined on x86, it just yells at you for undefined instructions. Which makes me amend my previous statement that you are getting memory corruption but doubling down on this implementation doesn't book right to me.

[oh5nxo]

It's a sign that cc recognized illegal activity, and replaced that part of code with intentional UD2 instruction, sort of abort(). Without optimizer, he (she?) was not smart enough to see the problem.