search for: run_dtors

...dtor_pairs *dtors ) { > try { > item_iterator *const that = static_cast<item_iterator*>( v_that ); > item *const result = static_cast<item*>( v_result ); > return that->next( result ); > } > catch ( ... ) { > run_dtors( dtors ); > throw; > } > } > > where run_dtors() would run through the array backwards calling the destructor functions in reverse order of construction. > > Would this work? If so, then I wouldn't have to mess with handing C++ exceptions from LLVM. But is ther...

...erent from what I proposed (putting the try/catch in the thunks)? (Ideally, I want to minimize layers of function calls.) Again for reference: > No reason. But if you have the 'try{}catch(...){}', then it should run the d'tors for you. There's no reason for you to have a "run_dtors" function there. -bw > extern "C" bool thunk_iterator_M_next( void *v_that, void *v_result, > dtor_pairs *dtors ) { > try { > item_iterator *const that = static_cast<item_iterator*>( v_that ); > item *const...

...2ac60 in ossl_init_thread_stop (locals=<optimized out>) at crypto/init.c:336 #2 0x00007f674872aee4 in OPENSSL_cleanup () at crypto/init.c:391 #3 0x00007f67491052e0 in __run_exit_handlers (status=0, listp=0x7f674948c5d8 <__exit_funcs>, run_list_atexit=run_list_atexit at entry=true, run_dtors=run_dtors at entry=true) at exit.c:83 #4 0x00007f674910533a in __GI_exit (status=<optimized out>) at exit.c:105 #5 0x00007f67490eb3f8 in __libc_start_main (main=0x555b35fbfbc0 <main>, argc=1, argv=0x7ffd4ede3588, init=<optimized out>, fini=<optimized out>, rtld_fini=&l...

...hat, void *v_result, dtor_pairs *dtors ) { try { item_iterator *const that = static_cast<item_iterator*>( v_that ); item *const result = static_cast<item*>( v_result ); return that->next( result ); } catch ( ... ) { run_dtors( dtors ); throw; } } where run_dtors() would run through the array backwards calling the destructor functions in reverse order of construction. Would this work? If so, then I wouldn't have to mess with handing C++ exceptions from LLVM. But is there a better "LLVM way" to...

...hat, void *v_result, dtor_pairs *dtors ) { try { item_iterator *const that = static_cast<item_iterator*>( v_that ); item *const result = static_cast<item*>( v_result ); return that->next( result ); } catch ( ... ) { run_dtors( dtors ); throw; } } - Paul

My project has a C++ library that I want to allow the user to use via some programming language to be JIT'd to call functions in said library. For the sake of simplicity, assume the library has classes like: class item { public: item(); item( int ); ~item(); // ... }; class item_iterator { public: virtual ~item_iterator(); virtual bool next( item *result ) = 0; };

...(locals=<optimized out>) > at crypto/init.c:336 > #2 0x00007f674872aee4 in OPENSSL_cleanup () at crypto/init.c:391 > #3 0x00007f67491052e0 in __run_exit_handlers (status=0, > listp=0x7f674948c5d8 <__exit_funcs>, > run_list_atexit=run_list_atexit at entry=true, > run_dtors=run_dtors at entry=true) at exit.c:83 > #4 0x00007f674910533a in __GI_exit (status=<optimized out>) at exit.c:105 > #5 0x00007f67490eb3f8 in __libc_start_main (main=0x555b35fbfbc0 <main>, > argc=1, argv=0x7ffd4ede3588, init=<optimized out>, > fini=<optimized o...

...from what I proposed (putting the try/catch in the thunks)? (Ideally, I want to minimize layers of function calls.) Again for reference: > > No reason. But if you have the 'try{}catch(...){}', then it should run the d'tors for you. There's no reason for you to have a "run_dtors" function there. How does the C++ implementation "know" to run the d'tors for me since the C++ objects that were created on the stack were created by JIT'd code, first via alloca to allocate StructTypes of the right size (char[sizeof(T)]) then calling a thunk of the form:...

...ut>) >> at crypto/init.c:336 >> #2 0x00007f674872aee4 in OPENSSL_cleanup () at crypto/init.c:391 >> #3 0x00007f67491052e0 in __run_exit_handlers (status=0, >> listp=0x7f674948c5d8 <__exit_funcs>, >> run_list_atexit=run_list_atexit at entry=true, >> run_dtors=run_dtors at entry=true) at exit.c:83 >> #4 0x00007f674910533a in __GI_exit (status=<optimized out>) at >> exit.c:105 >> #5 0x00007f67490eb3f8 in __libc_start_main (main=0x555b35fbfbc0 <main>, >> argc=1, argv=0x7ffd4ede3588, init=<optimized out>, >&gt...

This fixes the long-standing crash on close when nbdkit exits. I did try first to fix threads so we're using a proper thread pool, but that's difficult to implement. So this does the minimal change needed to fix the crash instead. There are still two segfaults that happen during running the test suite. One is deliberately caused (tests/test-captive.sh). The other appears to be an

...at I proposed (putting the try/catch in the thunks)? (Ideally, I want to minimize layers of function calls.) Again for reference: >> >> No reason. But if you have the 'try{}catch(...){}', then it should run the d'tors for you. There's no reason for you to have a "run_dtors" function there. > > How does the C++ implementation "know" to run the d'tors for me since the C++ objects that were created on the stack were created by JIT'd code, first via alloca to allocate StructTypes of the right size (char[sizeof(T)]) then calling a thunk of th...