-
Notifications
You must be signed in to change notification settings - Fork 98
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
p11-kit 0.24.1 fails assertions #495
Comments
Thank you for the report. As for the test failures, would anything change if you specify |
I've seen these (or similar assertions) before on macOS when running the pkcs11-provider tests, but as you noticed they don't seem to affect functionality, so I didn't spend a lot of time investigating. |
I see significantly fewer failures with
|
See #496. |
With PR #496 applied, all tests pass, except for one (57) that timeouts:
Testlog: testlog.txt If I want to install what I compiled into |
Please don't manually overwrite contents of The other opportunity would be changing the MacPorts Portfile to include these fixes, but considering the autotools build system currently works fine for that, I think this should be merged here and published into a release before MacPorts' Portfile should follow. |
There's a bunch of ports that appear to depend on The following seems a preferred alternative:
This is what I would absolutely prefer. I'm not crazy about even compiling p11-kit from the source myself, and will be happy to keep relegating this to Macports. So, the sooner this gets merged, and propagated to Macports - the better for me. |
Oh, test 57 keeps failing with timeout with
|
I cannot reproduce the timeout, it fails with an error for me, but I already identified the root cause for that. The timeout must be specific to your system. |
Great! Can I hope to see a merged fix, or at least a PR soon? |
Trying to compile the thing on Intel-based Mac (MacOS Ventura 13.3.1, Xcode-14.3), it fails to link with a local library. I think
|
Also, with the current master plus #496 applied, I'm getting this crash (which occurs after the result of the crypto operation has been returned):
for encryption, and the same trace except that it's in
Here's the link to the Update@simo5 perhaps you could see what's going on here? |
Some of the tools use opnessl directly and race at process exit with openssl deinitialization. |
@simo5 thank you - this setting alleviated the de-initialization problem!! |
I belive #496 should fix the problem reported in this issue when built with The question that remains is whether we should maybe make |
That might make sense. While we should investigate the root cause, the fixed closure support was added merely to prevent AVC denials when creating and running executable code on the fly (that is what libffi does internally on Linux). If libffi closures work ok on macOS, we don't need to use fixed closures. |
Assertions now OK. All tests pass too. Thank you! I guess it's time to close this issue. Hope the fixes make it to a release soon, and Macports picks them up. |
@ueno in the master, I still have one test failing:
How important is it, and can it be related to the problem I described elsewhere? UpdateThis failure actually could matter, because the crash reported (near the end of the post) in latchset/pkcs11-provider#234 (comment) fails in |
Yes, that's a real issue an should be fixed with #505. I'm not sure why it's not caught in the libffi CI target. |
Apple Silicon M2, MacOS Ventura 13.3.1, Xcode-14.3, OpenSSL-3.1.0, pkcs11-provider (current master), p11-kit v0.24.1, installed via Macports.
Despite the above bunch of failed assertions, apparently the decryption succeeds and produces correct output.
Still, these assertions are rather unnerving, and it would be great to fix their cause or get rid of them. ;-)
Update
Cloning this repo, building, and running tests (as your README suggests), showed a few failed tests:
The full test log: testlog.txt
Meson log, in case it's useful: meson-log.txt
The text was updated successfully, but these errors were encountered: