search for: atexit

Hey Guys, I am trying to get a python script running but I get the following error: atexit.register(atexit_handler) NameError: global name 'atexit' is not defined A Google search doesn't really help me, except confirm that I don't know anything about python:) Anyone got any ideas? Thanks, jlc

Hi everyone, hi Lang, I have a question about Orc JIT (and I think LLVM JIT in general). I am jitting some C++ code that calls atexit and registers a function at some address 0xdeadbeef. Everything is fine, but when the host program (the one that JITs C++ code) shuts down, then I see a crash: error: memory read failed for 0xdeadbeef With the following backtrace: * frame #0: 0x000000010b70b7a0 frame #1: 0x00007fff8ae0...

...3: warning: comparison between pointer and integer channels.c:2626: warning: passing arg 1 of `on_exit' from incompatible pointer type channels.c:2626: too few arguments to function `on_exit' make: *** [channels.o] Error 1 This was not good. After doing a little research I discovered that atexit() apparently doesn't work on my current system (in glibc > 2.1 it is declared external, which breaks things on Sparc...I don't claim to fully follow, so read the news groups for more info). Further reading indicated that on_exit() has a different parameter list than atexit(), as shown be...

> It's not the job of the Orc engine. I could argue about this, but I won’t :) > Just don't use atexit. The problem is that I run third-party programs. I cannot control them. > On 20. Nov 2017, at 01:04, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Nov 20, 2017 at 12:22:49AM +0100, Alex Denisov via llvm-dev wrote: >> JIT allocates and maps s...

http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From djm at mindrot.org 2002-04-23 23:29 ------- This should be fixed in -current CVS, please test ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

...e[1]: Entering directory `/root/wine/tools' make[2]: Entering directory `/root/wine/tools/specmaker' gcc -g -O2 -Wall -o specmaker dll.o main.o misc.o msmangle.o output.o search.o symbol.o dll.o: In function `dll_open': /root/wine/tools/specmaker/dll.c:83: undefined reference to `atexit' output.o: In function `output_spec_preamble': /root/wine/tools/specmaker/output.c:30: undefined reference to `atexit' output.o: In function `output_header_preamble': /root/wine/tools/specmaker/output.c:133: undefined reference to `atexit' output.o: In function `output_c_preambl...

...ctors 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 not be resolved. Any guidance would be MUCH appreciated. I am at a loss... Also, if you kno...

http://bugzilla.mindrot.org/show_bug.cgi?id=75 ------- Additional Comments From djm at mindrot.org 2002-01-23 17:16 ------- AFAIK atexit() should only take one arg. It looks like configure might not be finding your libc atexit() and is using the compat macro in defines.h. What does configure report when it looks for atexit()? Ben, the compat macro looks wrong too. It is currently defined as: # define atexit(a, NULL) on_exit(a, NUL...

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74 https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/lli.cpp#L631 Best, Matt On 11/23/2017 19:49, Stefan Gränitz via llvm-dev wrote: > Maybe the easiest workaround would be overriding symbol resolution...

...de, the only way to definitely avoid this kind of trouble is to never deallocate any code or data sections. Doug Binks mentioned that too in his cppcast about Runtime Compiled C++ http://cppcast.com/2016/05/doug-binks/ Am 21.11.17 um 14:20 schrieb Nikodemus Siivola via llvm-dev: > Transform the atexit into equivalent code you can control, run it > before the destructors of the JIT engine run? > > > On Tue, Nov 21, 2017 at 12:13 PM, Alex Denisov via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > It's not the job...

...nstructors, play with their linkage and visibility, and generally get involved in things I don't understand... Thanks, Geoff On Fri, 15 Jun 2018 at 11:23, Alex Denisov <1101.debian at gmail.com> wrote: > Hi Geoff, > > I hit the same problem some time ago. > The problem that atexit handlers are registered from the JITted code, and > the handlers point to the memory allocated by JIT. > When the host program exits it calls the atexit handlers, but the memory > is already deallocated by JIT. > That's basically the reason of the crash. > > From what I see Ex...

...------ Forwarded message ---------- Date: Wed, 23 Jan 2002 00:25:05 -0600 (CST) From: mouring at etoh.eviladmin.org To: bugzilla-daemon at mindrot.org Subject: Re: [Bug 75] Error compiling in ssh-agent.c > ------- Additional Comments From djm at mindrot.org 2002-01-23 17:16 ------- > AFAIK atexit() should only take one arg. It looks like configure might not be > finding your libc atexit() and is using the compat macro in defines.h. What does > configure report when it looks for atexit()? > > Ben, the compat macro looks wrong too. It is currently defined as: > > # define at...

...volved in things I don't understand... > > > > Thanks, > > Geoff > > > > On Fri, 15 Jun 2018 at 11:23, Alex Denisov <1101.debian at gmail.com> > wrote: > > Hi Geoff, > > > > I hit the same problem some time ago. > > The problem that atexit handlers are registered from the JITted code, > and the handlers point to the memory allocated by JIT. > > When the host program exits it calls the atexit handlers, but the memory > is already deallocated by JIT. > > That's basically the reason of the crash. > > > &gt...

...t; > > > > > Thanks, > > > Geoff > > > > > > On Fri, 15 Jun 2018 at 11:23, Alex Denisov <1101.debian at gmail.com> > wrote: > > > Hi Geoff, > > > > > > I hit the same problem some time ago. > > > The problem that atexit handlers are registered from the JITted code, > and the handlers point to the memory allocated by JIT. > > > When the host program exits it calls the atexit handlers, but the > memory is already deallocated by JIT. > > > That's basically the reason of the crash. > &gt...

...possible to know whether a function is ACTUALLY called until at runtime - function pointers, including those in vtables, may or may not actually get called, depending on the exact dynamic behaviour of the code. Then there will be functions implemented outside of the LLVM-IR for the program anyway. atexit is a good example of a function that takes a function pointer. Your code will not know what (if anything) atexit does with that function pointer, or if/when that function gets called. Of course, we, as humans, know how atexit works and when the function gets called, but some code will not know that...

OpenSSL 1.1 features a cleanup function that is automatically run on shutdown using atexit(3). This function frees all OpenSSL-allocated resources. In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant dovecot crypto module and is finally unloaded using dlclose(3). Until OpenSSL 1.0.1c this worked fine, however OpenSSL 1.0.1c makes sure[1] that the library stays...

...AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dh at onclick.org Sorry that I don't get it but I can't compile the portable OpenSSH since 3.0 up to the SNAP of 27.03.2002 (about a year now, am really in trouble!). I always stumble over libutil not being able to reference atexit. You now offer the option: --disable-libutil but it does not help. At the end of the configure process the list shows up: Libraries: -lutil -lz -lnsl -lcrypto -lcrypt This may be the reason for that: checking for libutil.h... no checking for library containing login... -lutil I don't...

The way `-ftest-coverage -fprofile-arcs` works at the moment it only flushes via `atexit()`. This patch allows you to flush the coverage at any point by calling `__llvm_gcov_flush` the same way `__gcov_flush` works for gcc. If there is another way of doing this, I might of missed it but I was looking for `__gcov_flush` and I did not find the equivalent in llvm at the moment. -- John...

...the end of my config.log file below. Most of the problems I saw mentioned were from vorbis-tools not finding the libraries, in which case pointing the config script was all that was necessary. On my machine, it seems to find the libraries ok, but ends up with an "undefined reference to `atexit'". Anybody have any suggestions? <p>configure:5614: checking for Ogg configure:5644: gcc -o conftest -O20 -ffast-math -mno-ieee-fp -D_REENTRANT -fsigned-char -DUSE_MEMORY_H -I/usr/include conftest.c -lm -L/usr/lib -logg 1>&5 /usr/lib/libogg.so: undefined reference to `...

Dear all, I'm writing an LLVM pass, and I want to insert a call instruction that takes a function pointer as a parameter. The effect would be the same as following: atexit(foo); Where foo is a function I insert with M.getOrInsertFunction(), which in LLVM is a Function class. I searched for a while and did not come up with a satisfying answer. Should I create a Value class of pointer type, or a Int64Ty for a pointer? How do I get the pointer to the function I create...