search for: __run_exit_handlers

...o execute a function it defines. That works (or pretends to). However, if I call the module's constructors first: exec_engine->runStaticConstructorsDestructors(false); exec_engine->runFunctionAsMain(function, argvec, NULL); execution still works, but my program crashes when it exits, in __run_exit_handlers(). I can't tell from gdb what exit handler is crashing, but no calls are made to atexit() or on_exit(); all exit handlers are installed via __cxa_atexit(). This may or may not be meaningful, but I am forced to compile with -fno-use-cxa-atexit, otherwise clang complains that __dso_handle could...

...o). However, if > I call the module's constructors first: > > > > exec_engine->runStaticConstructorsDestructors(false); > > exec_engine->runFunctionAsMain(function, argvec, NULL); > > > > execution still works, but my program crashes when it exits, in > __run_exit_handlers(). I can't tell from gdb what exit handler is crashing, > but no calls are made to atexit() or on_exit(); all exit handlers are > installed via __cxa_atexit(). > > > > This may or may not be meaningful, but I am forced to compile with > -fno-use-cxa-atexit, otherwise clang...

...t hook takes 22 seconds, which is 44x more than I am willing to pay. Most of the time is spent here: #0 0x00007ffff3b034cd in msync () at ../sysdeps/unix/syscall-template.S:82 #1 0x0000000003a8c818 in llvm_gcda_end_file () #2 0x0000000003a8c914 in llvm_writeout_files () #3 0x00007ffff2f5e901 in __run_exit_handlers The test depends on ~700 source files and so the profiling library calls msync ~700 times. Full chromium depends on ~12000 source files, so we'll be dumping the coverage data for 5 minutes this way. I understand that we have to support the lcov/gcov format (broken in may ways) and this may be t...

...ed signal SIGSEGV, Segmentation fault. 0x00007f6748cc2fb0 in ?? () (gdb) bt #0 0x00007f6748cc2fb0 in ?? () #1 0x00007f674872ac60 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...

...ll the module's constructors first: > > > > > > exec_engine->runStaticConstructorsDestructors(false); > > > exec_engine->runFunctionAsMain(function, argvec, NULL); > > > > > > execution still works, but my program crashes when it exits, in > __run_exit_handlers(). I can't tell from gdb what exit handler is crashing, > but no calls are made to atexit() or on_exit(); all exit handlers are > installed via __cxa_atexit(). > > > > > > This may or may not be meaningful, but I am forced to compile with > -fno-use-cxa-atexit, otherw...

Hello, I have few questions about coverage. Is there any user-facing documentation for clang's "-coverage" flag? The coverage instrumentation seems to happen before asan, and so if asan is also enabled asan will instrument accesses to @__llvm_gcov_ctr. This is undesirable and so we'd like to skip these accesses. Looks like GEP around @__llvm_gcov_ctr have special metadata

...ructors first: > > > > > > > > exec_engine->runStaticConstructorsDestructors(false); > > > > exec_engine->runFunctionAsMain(function, argvec, NULL); > > > > > > > > execution still works, but my program crashes when it exits, in > __run_exit_handlers(). I can't tell from gdb what exit handler is crashing, > but no calls are made to atexit() or on_exit(); all exit handlers are > installed via __cxa_atexit(). > > > > > > > > This may or may not be meaningful, but I am forced to compile with > -fno-use-cxa-atex...

...assRegistrationListener() (Pass.cpp:211) ==26332== by 0x15F2074: llvm::PassNameParser::~PassNameParser() (Pass.cpp:221) ==26332== by 0x1604973: llvm::cl::list<llvm::PassInfo const*, bool, llvm::PassNameParser>::~list() (in /home/ryoqun/rubinius/ryoqun/bin/rbx) ==26332== by 0x5EE4900: __run_exit_handlers (exit.c:78) ==26332== by 0x5EE4984: exit (exit.c:100) *1 http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/046828.html Regards, -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Avoid-Valgrind-s-still-reachable-leak-warnings.patch Type: application/...

...ine both /tmp/log and tests/test-suite.log. The stack trace from the crash is: Thread 2 (Thread 0x7f67a975d800 (LWP 22742)): #0 0x00007f67a9579250 in _dl_sort_fini () from /lib64/ld-linux-x86-64.so.2 #1 0x00007f67a9579402 in _dl_fini () from /lib64/ld-linux-x86-64.so.2 #2 0x00007f67a8817c68 in __run_exit_handlers () from /lib64/libc.so.6 #3 0x00007f67a8817cba in exit () from /lib64/libc.so.6 #4 0x00000000004046ac in main (argc=<optimized out>, argv=<optimized out>) at main.c:506 Thread 1 (Thread 0x7f67a099b700 (LWP 22745)): #0 0x00007f67a8870fc6 in strlen () from /lib64/libc.so.6 #1 0x0...

...rinterr malloc.c 5007 0x7ffff5ddab96 > 4 llvm::PassNameParser::~PassNameParser() /usr/lib/x86_64-linux-gnu/libLLVM-3.0.so.1 0x7fffc01b16c2 > 5 llvm::cl::list<llvm::PassInfo const*, bool, llvm::PassNameParser>::~list() /home/me/myApp/build/plugins/myApp/libLLVM.so 0x7fffc7b25568 > 6 __run_exit_handlers exit.c 78 0x7ffff5d97901 > 7 __GI_exit exit.c 100 0x7ffff5d97985 > 8 __libc_start_main libc-start.c 258 0x7ffff5d7d774 > 9 _start 0x426b29 > --------------------------------------- > Paweł

...039e 3 malloc_printerr malloc.c 5007 0x7ffff5ddab96 4 llvm::PassNameParser::~PassNameParser() /usr/lib/x86_64-linux-gnu/libLLVM-3.0.so.1 0x7fffc01b16c2 5 llvm::cl::list<llvm::PassInfo const*, bool, llvm::PassNameParser>::~list() /home/me/myApp/build/plugins/myApp/libLLVM.so 0x7fffc7b25568 6 __run_exit_handlers exit.c 78 0x7ffff5d97901 7 __GI_exit exit.c 100 0x7ffff5d97985 8 __libc_start_main libc-start.c 258 0x7ffff5d7d774 9 _start 0x426b29 ---------------------------------------

...ntation fault. mnl_socket_close (nl=0x0) at socket.c:248 248 int ret = close(nl->fd); (gdb) bt #0 mnl_socket_close (nl=0x0) at socket.c:248 #1 0x0000000000410f79 in netlink_close_sock () at src/netlink.c:45 #2 0x00007ffff7de9fcf in _dl_fini () at dl-fini.c:253 #3 0x00007ffff717fa91 in __run_exit_handlers (status=2, listp=0x7ffff74ec5c8 <__exit_funcs>, run_list_atexit=run_list_atexit at entry=true) at exit.c:77 #4 0x00007ffff717fb15 in __GI_exit (status=<optimized out>) at exit.c:99 #5 0x0000000000419b60 in memory_allocation_error () at src/utils.c:24 #6 0x0000000000410f3a in net...

...lt. > 0x00007f6748cc2fb0 in ?? () > (gdb) bt > #0 0x00007f6748cc2fb0 in ?? () > #1 0x00007f674872ac60 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_m...

...fb0 in ?? () >> (gdb) bt >> #0 0x00007f6748cc2fb0 in ?? () >> #1 0x00007f674872ac60 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 0x0000...

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

Hi all, a user contacted me about a segfault when installing WGCNA package dowloaded from CRAN. I also see a segfault like that on certain installs of R. The package passes all CRAN checks, so presumably this has something to do with the R installation or environment. The R versions here are not the newest but I would guess that this is not an R version issue. I'm attaching two

Hi, when I tested building nbdkit 1.1.15 in a current Debian chroot, I ran into the following test failure. A repeated build went fine through the tests and so far I have not been able to reproduce it with the previous version. The failing build was done using a clean Debian/sid, amd64 chroot spawned by sbuild. Cheers, -Hilko FAIL: test-python =================