Exit code 3 after adding Diesel r2d2 on Rocket #2947
-
|
Hi all! I have an issue with the My rocket app is exiting with code 3, without any message or log on Windows 10. I found that this is occurred by the The detailed problem is described in rwf2/Rocket#1931 and rwf2/Rocket#1931 (comment). Is there any work-around for this issue? Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 61 replies
-
|
I'm not aware of this issue, so I fear you need to provide much more information especially the following information:
(Another related note: As I do not have access to a windows 10 machine I cannot just take random code and try to reproduce platform specific issues.) EDIT: Another thing that may be useful to know is whether libpq was compiled in a thread safe mode or not. I fear in the second case this "behaviour" is expected. |
Beta Was this translation helpful? Give feedback.
-
Can you provide a link for the download?
See https://www.postgresql.org/docs/current/libpq-threading.html for details.
It's totally fine to ask those question, but please understand that I need to ask for details to be able to understand the problem and that I cannot promise any solution. |
Beta Was this translation helpful? Give feedback.
-
|
Another thing I would try is to see if it's possible to "reproduce" this without r2d2 and rocket. The following minimal test program just opens up a number of connection from different threads at the same time. If it's a racing condition in diesel (or libpq) the issue should show up here as well. If that's not the case we know at least that the connection implementation should be fine, which means this is likely a pool issue then. Can you try running the following program and report back? You likely need to adjust extern crate diesel;
use diesel::prelude::*;
use std::thread;
use std::sync::{Arc, Barrier};
fn main() {
const THREAD_COUNT: usize = 10;
let db_url = "postgres://localhost/diesel_test";
let b = Arc::new(Barrier::new(THREAD_COUNT));
let mut handles = Vec::new();
for i in 0..THREAD_COUNT {
let b = Arc::clone(&b);
let h = thread::spawn(move || {
b.wait();
let _ = PgConnection::establish(db_url).unwrap();
println!("Successfully initialized connection {}", i);
});
handles.push(h);
}
for h in handles {
h.join().unwrap();
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Hello weiznich, I came across this thread having the exact same issue as AcrylicShrimp, except I was using actix-web instead of Rocket. I was able to reproduce the same exit code: 3 error on my Windows 10 machine rustc 1.56.1 using the sample code that you provided Let me know if you need any additional info on the error. |
Beta Was this translation helpful? Give feedback.
-
|
As I do not have access to a windows 10 machine to reproduce this I've added the test program as test case to our test suite: #2951. I expected to reproduce the failure on our CI, but that didn't work as expected 😞 This means I likely need more help to investigate this issue. Let me summarize what I think to know about this problem:
To move forward on this we likely need to collect more information. It would be helpful if you @CDouv or @AcrylicShrimp could:
I expect this to be somehow related to
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry for this late response! I tested the PR and got some information for the About the PRI cannot test your PR properly. the test halts after random successful logs. This problem occurs even if the PR you added is stripped out. As you can see, the About the
|
Beta Was this translation helpful? Give feedback.
-
Can you try running the tests with
👍 Will have a look at that.
That leaves two possible causes on my list 🤔 I will need some time to think about a way to verify that it is one or the other. |
Beta Was this translation helpful? Give feedback.
-
|
@clemens-msupply I did see that. I remember getting a similar stacktrace once, I think. Oh, in case I didn't make this clear, the |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for running the bisect 👍 This commit seems to have at least some connection to the error message mentioned on the postgres mailing list, so it seems plausible that this causes the issue. I would suggest the following next steps:
|
Beta Was this translation helpful? Give feedback.
-
|
To add a few additional thoughts here: @clemens-msupply mentioned on the mailing list
Combined with the linked patch that seems to indicate an issue with getting the host name. So its probably either |
Beta Was this translation helpful? Give feedback.
-
|
Here's today's debugging session: https://gist.github.com/hut8/3b25e6a581a600589bdc62644734de18 Unfortunately, I can't make much of this. Earlier, I pointed out that the I will report this on the mailing list with this additional info, and refer to @clemens-msupply 's thread. |
Beta Was this translation helpful? Give feedback.
-
|
I finally found the actual problem and a real solution. The real problemYes, the problem is in gettext/libintl. It turns out that in Postgres, according to one of the maintainers from EnterpriseDB:
It is almost impossible to generate a PDB file for gettext/libintl because it must be built with mingw which doesn't produce those. With more effort than I would like to make, there is a tool developed by the D language community that can do this: https://github.com/rainers/cv2pdb The libintl version that is distributed with EnterpriseDB Postgres is named libintl-9.dll. You would think that this is newer than libintl-8.dll. But you would be wrong. See this explanation. This really threw me off! It turns out, therefore, that libintl-8.dll contains newer code than libintl-9.dll The only code that really calls abort() anywhere in the stacktrace has to do with threading macros. So it's something to do with that. There is this one commit that caught my eye: #ifdef _LIBC
__libc_rwlock_fini (domain->conversions_lock);
+#else
+ gl_rwlock_destroy (domain->conversions_lock);
#endif
goto invalid;
}This code is only present in tags v0.20, v0.20.1, v0.20.2, and v0.21. So I grabbed some new binaries that would contain this code from github (see the solution) and verified that the versions that contain this patch do not have the issue. The ones that do not contain the patch do have the issue. For some comic relief, here is real gem I found in the source: #ifdef __GNUC__
# define ZERO 0
#else
# define ZERO 1
#endifSolution
I asked if we could expect a non-broken libintl DLL in upcoming versions (after they figure out the performance regression). I don't know yet, but at least we have a fix. |
Beta Was this translation helpful? Give feedback.
-
|
@xxgunnery I want to clarify one thing here: This issue is not related to rust at all. Its an issue with two C libraries that happens independently of rust or diesel. We somehow just manage to trigger it. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @hut8 for the solution, works great! I just deployed Postgres 16 and it still ship the the wrong lib. |
Beta Was this translation helpful? Give feedback.
-
|
2024 they still havn't fixed it😂 |
Beta Was this translation helpful? Give feedback.
-
|
this worked, I think the better option is placing it the postgres bin in the installation folder, after changing the name and copying it. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
and others
I finally found the actual problem and a real solution.
The real problem
Yes, the problem is in gettext/libintl. It turns out that in Postgres, according to one of the maintainers from EnterpriseDB:
It is almost impossible to generate a PDB file for gettext/libintl because it must be built with mingw which doesn't produce those. With more effort than I would like to make, there …