I think the problem is outbuf size, as openssl doc (https://www.openssl.org/docs/manmaster/man3/RSA_public_encrypt.html) says: to must point to RSA_size(rsa) bytes of memory, but the code use inbuf_plain.length
------------------ ???????? ------------------ ??????: "Al Thomas via vala-list"<[email protected]>; ????????: 2020??2??23??(??????) ????10:34 ??????: "vala-list"<[email protected]>; ????: Re: [Vala] ?????? ?????? About VAPI's instance position > On Sunday, 23 February 2020, 10:32:48 GMT, ???? via vala-list <[email protected]> wrote: > 1. crashed at RSA_public_encrypt() on msys2 on windows 7 > #8 0x0000000067e4fb2f in libcrypto-1_1-x64!BN_clear_free () > #9 0x0000000067e474ce in libcrypto-1_1-x64!BN_CTX_free () > #10 0x0000000067f618d8 in libcrypto-1_1-x64!RSA_padding_add_PKCS1_OAEP () > 2. crashed at RSA_private_decrypt() on archlinux: > unmap_chunk(): invalid pointer > #5 0x00007ffff6d1495d in BN_clear_free () at /usr/lib/libcrypto.so.1.1 > #6 0x00007ffff6d0d02f in BN_CTX_free () at /usr/lib/libcrypto.so.1.1 Calls to BN_CTX_free and BN_clear_free suggest some problem in the memory management when using BIGNUM: https://github.com/openssl/openssl/blob/master/include/openssl/bn.h That could be difficult to track down. You need to understand how memory in the buffers you are passing is being used and the difference between stack allocated and heap allocated memory. One thing you can try is adding the `--debug` switch when calling `valac`. This should help show the Vala source code line numbers in the backtraces. Regards, Al _______________________________________________ vala-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/vala-list _______________________________________________ vala-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/vala-list
