Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

panic!ing twice crashes PG with "Illegal instruction" #118

Open
auterium opened this issue Dec 31, 2019 · 7 comments
Open

panic!ing twice crashes PG with "Illegal instruction" #118

auterium opened this issue Dec 31, 2019 · 7 comments

Comments

@auterium
Copy link
Contributor

OS

Ubuntu 18.04 (Windows Subsystem for Linux)

Code

panicking example package

Issue

Rust panic!() is caught and handled properly on the first call, but if called again, the server crashes:
image

Here's PG logs:
image

That little extra weird stuff

This also happens when using error!() macro, but it requires 3 executions:
image

Here;s PG logs:
image

@bluejekyll
Copy link
Owner

Error, fatal and panic all cause PG to abort the transaction, where panic will cause a full restart. The illegal obstruction is concerning though.

Is this a double panic? Or is it a panic, and then a different transaction also panicking?

@auterium
Copy link
Contributor Author

Unless psql is not setting AUTOCOMMIT then yes, they are separate transactions panicking

@bluejekyll
Copy link
Owner

This is happening on Windows? I wonder if this behavior can be reproduced on a vanilla Linux box.

@auterium
Copy link
Contributor Author

Same error happens in a Docker container running PG10
image

@bluejekyll
Copy link
Owner

I haven’t looked into this, yet, but what is the expected behavior of Postgres when it panics? It might do exactly this. It would be interesting if we had a test case that showed this with and without pg-extend. That would require a vanilla C extension I think.

@auterium
Copy link
Contributor Author

auterium commented Jan 2, 2020

Looking at PG source code, I found this:
image

The important part is:

If elevel >= ERROR, the call will not return; we try to inform the compiler of that via pg_unreachable()

So, if the log level is ERROR or higher, there will be a different behaviour (no return). Perhaps this might explain the weird behaviour?

@bluejekyll
Copy link
Owner

Yes. That’s what I was trying to explain. Error and higher log statements have the side effect of killing the transaction/process/server, depending on which you use.

It’s really ugly imo, but that’s the way it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants