QFile::close() leads to SIGILL

JonB

Didn't your compiler warn about bool function with no return at end?
You don't use the return result from your call in main().
Regardless of these, how does omitting a return result lead to a SIGILL?

Christian Ehrlicher

@JonB said in QFile::close() leads to SIGILL:

Regardless of these, how does omitting a return result lead to a SIGILL?

It's undefined behavior.

JonB

@Christian-Ehrlicher
Interesting! Then I'm even more surprised the OP's compiler didn't issue any warning for this code....

Do you have a reference for "It's undefined behavior"? Of course I know if you test the result you don't know what you'll get, but I'd like to read up on what it has to say if you fail to return any result, leading to possible crash.

Many, many years ago I used a C compiler on some unmentionable home computer system. I think it was a 6502 CPU. There, the compiler used the hardware stack to return the (two bytes) of any function result. What this meant was: I had to go through every line of code, working on all other C systems (program was cross-platform), so that if any function returned a value you had to assign that to a variable (or e.g. pass it as a value to another function, etc.). Failure to do so left a number on the stack after the function call, leading to later crash. What this meant was, for example, I had to find & change every single printf(...) in existing code to dummy = printf(), and similar for the hundreds of other functions which happened to return some value we don't care about...! :( And I still don't believe that behaviour was ever "allowed" in a C compiler.

Christian Ehrlicher

@JonB said in QFile::close() leads to SIGILL:

Do you have a reference for "It's undefined behavior"?

Don't return anything when the function should is undefined behavior by default :)

leading to possible crash.

It may also work, but it may also eat kittens. It depends on the compiler, the optimization level, the moon phase, ...

I know that one compiler did not warn about this kind of stuff, gcc 7.5 at least prints a warning (but compilation does not fail)

JonB

@Christian-Ehrlicher
Saying that "no return result" leads to "undefined behaviour" on the return result is one thing. That's not what I'm asking. Saying that the "undefined behaviour" could lead to "crash" (e.g. on exiting function) is quite another. I need a reference here! I'm going to have a look....

P.S.
What is that you & @Chris-Kawa have about threatening my fluffy kitten the whole time? She is now getting quite alarmed about these threats....

Christian Ehrlicher

@JonB said in QFile::close() leads to SIGILL:

Saying that the "undefined behaviour" could lead to "crash" (e.g. on exiting function) is quite another.

Undefined behavior is ... well undefined. anything can happen. My compiler returns '6' for this piece of code:

int foo()
{
	printf("Hello\n");
}

int main(int argc, char *argv[])
{
    printf("foo: %d\n", foo());
    return 0;
}

and '2116800' when I remove the printf() statement.

JonB

@Christian-Ehrlicher
Yes, but you know that is not the issue we are discussing! You know we are not talking about what the return result number is, we are talking about "crashing" on the } of foo() (or at the caller) because foo() does not have a return statement.

The following also has "undefined behaviour" (in what it prints), but I don't expect it to "crash":

int z;
printf("%d\n", z);

Christian Ehrlicher

Again: it's undefined - anything can happen, in this case it crashed.

JonB

@Christian-Ehrlicher
For the record, I have read what I can from various stackoverflow posts, etc. I do accept (now) that non-void no-return => UB => "anything may happen including crash". I was not aware of this, interesting, and thank you. Note however that there was no mention of damage to nearby kittens, either in C++ standard or in posts, so I am calming mine down about this (apart from, I have assured her this is one error I have never made)!

SGaist

Hi,

@JonB said in QFile::close() leads to SIGILL:

The following also has "undefined behaviour" (in what it prints), but I don't expect it to "crash":
int z;
printf("%d\n", z);

Strictly speaking it's not undefined behaviour. You will print a random value from an uninitialized int variable.

As @Christian-Ehrlicher already wrote undefined behaviour can be anything from funky values to a crash.

I had once to debug a strange crash that in the end was due to a missing return statement for a QString and the return value wasn't even used. For the fun of experimenting, I changed the return type to int and no crash anymore. That's what undefined behaviour is. That took me quite a while to find because the original warning was swamped in a tons of other warnings (words of the original developer: don't care these are just warnings), the return value being ignored, I did not take notice immediately that the return statement was missing and the code was so involved that tracing the crash correctly was pretty hard as is also required external hardware (

JonB

@SGaist said in QFile::close() leads to SIGILL:

Strictly speaking it's not undefined behaviour. You will print a random value from an uninitialized int variable.

"No", that's what I was saying, but I think you are "incorrect" here! [Hesitant, you usually shoot me down, fools rush in where... :) ]

The best "official" I can find is https://en.cppreference.com/w/cpp/language/ub. Note the difference between

unspecified behavior: Each unspecified behavior results in one of a set of valid results.
undefined behavior: there are no restrictions on the behavior of the program

Then note that (confusingly) it uses the abbreviation UB, which if you read carefully is the undefined rather than the unspecified behaviour. I take this from:

Because correct C++ programs are free of undefined behavior, compilers may produce unexpected results when a program that actually has UB

Hence I understand UB == undefined behaviour. Then proceed to the examples.

    std::size_t a;
    if(x) // either x nonzero or UB
        a = 42;

and

bool p; // uninitialized local variable
if(p) // UB access to uninitialized scalar
    std::puts("p is true");
if(!p) // UB access to uninitialized scalar
    std::puts("p is false");

So if UB == undefined behaviour, they are saying these could "crash". Otherwise you have to show that this UB == unspecified behaviour, which I do not see from the text I quoted. That's my reading, don't you think?

Christian Ehrlicher

@JonB said in QFile::close() leads to SIGILL:

they are saying these could "crash".

Correct, since x is not defined the compiler may decided to e.g. throw an exception, quit the program or simply use the value which it finds at the specified address.

JonB

@Christian-Ehrlicher
Going all the way back to the @Sedi's original

Qt 5.15.0 for Android, working on a Win10 machine

Purely OOI, what compiler does this mean he will be using? It would be interesting to see from one of those "web public compilers" what code it generates that leads to SIGILL....

Christian Ehrlicher

I would guess it's clang: https://godbolt.org/z/qGaKeM
/edit: msvc doesn't even compile it

JonB

@Christian-Ehrlicher
Thanks Christian. That "Compiler Explorer" site doesn't seem to be one which has an option of running code? Do you know of one which offers the necessary compiler but also runs code? I'd like to see that SIGILL actually happen, as per the OP :)

Or, failing that, can you explain what instruction in the generated code would actually cause it? Remember, the OP doesn't actually use the returned result from the function (which doesn't return a result), his case is just supposed to be:

bool func()
{
}

void main()
{
  func();
}

Christian Ehrlicher

@JonB said in QFile::close() leads to SIGILL:

Or, failing that, can you explain what instruction in the generated code would actually cause it?

Simply take a look at the godbolt assembler output and read the tooltip :)

doSomething():                       # @doSomething()
        push    rbp
        mov     rbp, rsp
        ud2

SGaist

@JonB said in QFile::close() leads to SIGILL:

"No", that's what I was saying, but I think you are "incorrect" here! [Hesitant, you usually shoot me down, fools rush in where... :) ]

I see your point now. Semantic is quite complex and your analysis is correct :-)
Undefined VS Unspecified and then using an abreviation that fits both is not really a good idea when documenting something.

JonB

@SGaist said in QFile::close() leads to SIGILL:

Undefined VS Unspecified and then using an abreviation that fits both is not really a good idea when documenting something.

100% !

JonB

@Christian-Ehrlicher said in QFile::close() leads to SIGILL:

Simply take a look at the godbolt assembler output and read the tooltip :)

Wow! Just wow! Well, I certainly do see how the compiler has gone out of its way to let me drop into a SIGILL when I fail to return something :)

SeDi

@Christian-Ehrlicher said in QFile::close() leads to SIGILL:

I would guess it's clang: https://godbolt.org/z/qGaKeM

You are right. Sorry for the delay, after setting the thread to "solved" I didn't ever look into it until I just now noticed this little red warning about unread messages :-)