Seg fault on bad case statement

[nyankers]

I just found this right now, so I haven't looked into why it's happening yet beyond gdb suggesting the crash is happening in parser.y:483 letting me quickly reproduce it in a fresh environment.

void test(int x)
{
    switch (x) {
        case BAD_CONSTANT:
        default:
            break;
    }
}

Compiling the above code causes a seg fault for me on the latest commit. Per its name, BAD_CONSTANT is in fact an undefined identifier.

[shentino]

@nyankers would I be correct to guess that the proper response is a compile error?

[nyankers]

Yup. It will do that in various mutations of the above, e.g. if you have code after the bad case, if it's not a default immediately afterward, etc.

[dworkin]

Simple as bugs go. Should be fixed by f0a002616a0cdb4f56ae547333c79cfe2c36c45c.

[nyankers]

Looks fixed to me, thanks!

[nyankers]

Somehow I got another possibly unrelated seg fault on my own server while upgrading everything (via upgrade /lib/kernel/auto.c) after taking the latest update, but it seems to have just somehow been in a bad state. For some reason, there was a mapping array such that hashmod was true but hashed was NULL. Fixing a compilation error somehow resolved this, and more puzzling, after upgrading everything following that fix, the error no longer happens even if I recreate the original compilation error.

Dunno if that's valuable to know considering I can't reproduce it at this stage, but I saw you did some changes to mappings so I figured I'd report this vague finding. u.u

[dworkin]

such that hashmod was true but hashed was NULL.

That was enough to go on, I fixed a situation where this might occur.

[nyankers]

I swapped back to an older revision on my server for now, I'll probably create a test environment to fiddle with this stuff a bit more. One other thing I noticed is that there was some sporadic object data loss, e.g. an object-scope string became nil and stuff like that (they were objects that inherited a number of other object variables, including at least one array and mapping), if that means anything to you. Doesn't seem to have impacted many objects though.

I'll create further issues as I'm able to reproduce things.

[dworkin]

You experienced these issues even with the latest commit?

[nyankers]

Yeah, it looks unrelated to these changes after all, it happened again on me. I'll have to see if I can reproduce the exact steps, but it's something like an obj is inheriting several libs which provide data, and after adding one lib as a prerequisite to another, clones of that obj get their data all out of order (for example returning an int array for a variable that should exclusively contain a typed object).

It's happening before and after the mapping/LWO changes.

I'll try to recreate it in a fresh environment tomorrow, if I'm able to (before you fix it, haha), I'll make a new issue for it, since it's unrelated to this one. I think this one can be closed, unless you have more questions. ^^;