[英]Z3 raises invalid memory access with JNA
我在jna中使用java中的Z3 C api。 我經常獲得無效的內存訪問,但只能使用windows(.dll)和mac os(.dylib)庫。 當我使用linux(.so)時,它不會發生。
我暫時解決了這個問題,從來沒有調用dec_ref
程序,包括ast和所有其他對象(我仍然調用inc_ref
procs,我在開頭使用mk_context_rc
)。 當然,這種解決方案是不可持續的。
我想這是由於某處的內存管理。 即使我只是使用mk_context
它仍然崩潰。
在線程中, JNA簡單函數調用在linux(x64)上工作但在Windows(x86)上沒有用戶遇到類似的問題,結果發現這是由於一些編譯配置。
這是我得到的例外(在Mac OS X 10.6.8上)
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000000c
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
這是失敗的痕跡
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libz3.dylib 0x00000001250d4d64 unsigned int ast_array_hash<expr>(expr* const*, unsigned int, unsigned int) + 244
1 libz3.dylib 0x00000001250cb16a ast_manager::register_node_core(ast*) + 36
2 libz3.dylib 0x00000001250cbeae ast_manager::mk_app_core(func_decl*, unsigned int, expr* const*) + 134
3 libz3.dylib 0x00000001250cc30d ast_manager::mk_app(func_decl*, unsigned int, expr* const*) + 749
4 libz3.dylib 0x000000012528c194 map_proc::reconstruct(app*) + 214
5 libz3.dylib 0x00000001254830b8 void for_each_expr_core<qe::lift_foreign_vars, obj_mark<expr, bit_vector, default_t2uint<expr> >, false, false>(qe::lift_foreign_vars&, obj_mark<expr, bit_vector, default_t2uint<expr> >&, expr*) + 760
6 libz3.dylib 0x00000001254832c9 qe::lift_foreign_vars::lift(obj_ref<expr, ast_manager>&) + 61
7 libz3.dylib 0x00000001254833a6 qe::datatype_plugin::simplify(obj_ref<expr, ast_manager>&) + 92
8 libz3.dylib 0x000000012546b1a7 qe::quant_elim_plugin::check(unsigned int, app* const*, expr*, obj_ref<expr, ast_manager>&, bool, ref_vector<app, ast_manager>&, qe::def_vector*) + 535
9 libz3.dylib 0x000000012546b8f9 qe::quant_elim_new::eliminate_block(unsigned int, app* const*, obj_ref<expr, ast_manager>&, ref_vector<app, ast_manager>&, bool, qe::def_vector*) + 445
10 libz3.dylib 0x000000012545f2cb qe::quant_elim_new::eliminate_exists(unsigned int, app* const*, obj_ref<expr, ast_manager>&, ref_vector<app, ast_manager>&, bool, qe::def_vector*) + 67
11 libz3.dylib 0x0000000125462170 qe::quant_elim_new::eliminate_exists_bind(unsigned int, app* const*, obj_ref<expr, ast_manager>&) + 88
12 libz3.dylib 0x000000012545c0ba qe::expr_quant_elim::elim(obj_ref<expr, ast_manager>&) + 1012
13 libz3.dylib 0x000000012545cb75 qe::expr_quant_elim::operator()(expr*, expr*, obj_ref<expr, ast_manager>&) + 113
14 libz3.dylib 0x000000012548b993 qe_tactic::imp::operator()(ref<goal> const&, sref_buffer<goal>&, ref<model_converter>&, ref<proof_converter>&, obj_ref<dependency_manager<ast_manager::expr_dependency_config>::dependency, ast_manager>&) + 783
15 libz3.dylib 0x00000001255debfa cleanup_tactical::operator()(ref<goal> const&, sref_buffer<goal>&, ref<model_converter>&, ref<proof_converter>&, obj_ref<dependency_manager<ast_manager::expr_dependency_config>::dependency, ast_manager>&) + 14
16 libz3.dylib 0x00000001255d5e3d exec(tactic&, ref<goal> const&, sref_buffer<goal>&, ref<model_converter>&, ref<proof_converter>&, obj_ref<dependency_manager<ast_manager::expr_dependency_config>::dependency, ast_manager>&) + 109
17 libz3.dylib 0x0000000125070ed8 _tactic_apply + 680
18 libz3.dylib 0x00000001250711d9 Z3_tactic_apply + 105
19 jna4404318687023840668.tmp 0x000000010a00cd1c ffi_call_unix64 + 76
20 jna4404318687023840668.tmp 0x000000010a00c884 ffi_call + 644
21 jna4404318687023840668.tmp 0x000000010a003ca5 Java_com_sun_jna_Native_ffi_1prep_1cif + 1605
22 jna4404318687023840668.tmp 0x000000010a004282 Java_com_sun_jna_Native_invokePointer + 34
23 ??? 0x00000001031cfd2e 0 + 4347198766
24 ??? 0x00000001031cd658 0 + 4347188824
25 ??? 0xffb89c44ff5c4272 0 + 18426649695542329970
也許他們有助於理解我做錯了什么
根據您問題中的評論,您似乎正在使用僅在新Z3 API中提供的策略和其他功能。 從版本4.0開始,引用計數是在Z3 API中管理內存的默認方法。 Z3 API仍然支持舊的內存管理策略(當使用API Z3_mk_context
而不是Z3_mk_context_rc
時啟用它)。 但是,舊的內存管理策略不適用於4.0版中引入的新對象(如Solvers
, Tactics
等)。
Z3發行版包含一個Python API。 Python API的源代碼位於Z3發行版的子目錄python
中。 它演示了如何將Z3 API集成到托管語言(如Python)中。 我相信可以使用類似的方法在Java中集成Z3 API。 我們的想法是用Java對象包裝器包裝每個Z3對象。 引用計數器應在構造函數中遞增,並在Java垃圾收集器回收包裝器時遞減。
引發異常的原因是我的主程序和java垃圾收集器同時訪問Z3。 我解決了只是讓Library
對象線程安全,用Native.synchronizedLibrary方法包裝它
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.