Displaying 3 results from an estimated 3 matches for "0xf670".
Did you mean:
0x670
2020 Oct 01
2
OrcV1 removal
...nt from
* adding this to the JIT).
*/
void LLVMOrcDisposeThreadSafeModule(LLVMOrcThreadSafeModuleRef TSM);
but when using -fsanitize-leaks I see:
Direct leak of 9192 byte(s) in 383 object(s) allocated from:
#0 0x7fe249127670 in operator new(unsigned long) (/lib/x86_64-linux-gnu/liblsan.so.0+0xf670)
#1 0x7fe1bfc1cbc0 in LLVMOrcCreateNewThreadSafeModule (/home/andres/build/llvm-project/master/debug/install/lib/libLLVMOrcJIT.so.12git+0x38bbc0)
#2 0x7fe245f6ea6d in llvm_compile_module /home/andres/src/postgresql/src/backend/jit/llvm/llvmjit.c:606
#3 0x7fe245f6e0b0 in llvm_get_functio...
2020 Oct 01
2
OrcV1 removal
Hi,
On 2020-09-30 19:00:45 -0700, Lang Hames wrote:
> Ok -- I'll make getting the new lookup API working a priority then.
Cool.
> > I see a memory leak with OrcV2 that I didn't see with V1. I'm not yet
> > sure where exactly they're coming from. Possible that I'm just missing a
> > step somewhere. Or something around the removable code support