search for: realoffset

...Engine/MCJIT/test-global-init-nonzero-remote.ll All of them fail with assertion: lli: /usr/local/google/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:230: void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry &, uint64_t, uint64_t, uint32_t, int64_t): Assertion `RealOffset <= (2147483647) && RealOffset >= (-2147483647-1)' failed. The reason is that AddressSanitizer replaces system malloc with its own allocator, which allocates memory at "unusual" parts of heap and the difference between pointers can be significant (and doesn't fit in...

Hi, We are seeing sporadic crashes since we migrated to MCJIT on Win64. The same tests pass without issues on Mac64 and Linux64. The issue is this assertion failure in RuntimeDyldELF.c: RealOffset <= INT32_MAX && RealOffset >= INT32_MIN I haven't managed to successfully catch the failure in Visual to try and debug it. Any tips on how to make progress? Oh, and we're on LLVM 3.5. Thanks. Ram -------------- next part -------------- An HTML attachment was scrubbed... UR...

...gt; ** ** > > All of them fail with assertion:**** > > lli: > /usr/local/google/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:230: > void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry > &, uint64_t, uint64_t, uint32_t, int64_t): Assertion `RealOffset <= > (2147483647) && RealOffset >= (-2147483647-1)' failed.**** > > ** ** > > The reason is that AddressSanitizer replaces system malloc with its own > allocator, which**** > > allocates memory at "unusual" parts of heap and the difference between...

...a <artagnon at gmail.com> > wrote: > >> Hi, >> >> We are seeing sporadic crashes since we migrated to MCJIT on Win64. The >> same tests pass without issues on Mac64 and Linux64. The issue is this >> assertion failure in RuntimeDyldELF.c: >> >> RealOffset <= INT32_MAX && RealOffset >= INT32_MIN >> >> I haven't managed to successfully catch the failure in Visual to try and >> debug it. Any tips on how to make progress? >> >> Oh, and we're on LLVM 3.5. >> >> Thanks. >> >> Ram...

...Engine/MCJIT/test-global-init-nonzero-remote.ll All of them fail with assertion: lli: /usr/local/google/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:230: void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry &, uint64_t, uint64_t, uint32_t, int64_t): Assertion `RealOffset <= (2147483647) && RealOffset >= (-2147483647-1)' failed. The reason is that AddressSanitizer replaces system malloc with its own allocator, which allocates memory at "unusual" parts of heap and the difference between pointers can be significant (and doesn't fit in...

...;>> Hi, >>>> >>>> We are seeing sporadic crashes since we migrated to MCJIT on Win64. The >>>> same tests pass without issues on Mac64 and Linux64. The issue is this >>>> assertion failure in RuntimeDyldELF.c: >>>> >>>> RealOffset <= INT32_MAX && RealOffset >= INT32_MIN >>>> >>>> I haven't managed to successfully catch the failure in Visual to try >>>> and debug it. Any tips on how to make progress? >>>> >>>> Oh, and we're on LLVM 3.5. >>...

...gt; **** > > All of them fail with assertion:**** > > lli: > /usr/local/google/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:230: > void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry > &, uint64_t, uint64_t, uint32_t, int64_t): Assertion `RealOffset <= > (2147483647) && RealOffset >= (-2147483647-1)' failed.**** > > **** > > The reason is that AddressSanitizer replaces system malloc with its own > allocator, which**** > > allocates memory at "unusual" parts of heap and the difference between...

...Engine/MCJIT/test-global-init-nonzero-remote.ll All of them fail with assertion: lli: /usr/local/google/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:230: void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry &, uint64_t, uint64_t, uint32_t, int64_t): Assertion `RealOffset <= (2147483647) && RealOffset >= (-2147483647-1)' failed. The reason is that AddressSanitizer replaces system malloc with its own allocator, which allocates memory at "unusual" parts of heap and the difference between pointers can be significant (and doesn't fit in...

...hanks, > > Dale > > > ------------------------------ > *From:* Lang Hames <lhames at gmail.com> > *Sent:* Friday, May 22, 2015 7:55 PM > *To:* Keno Fischer > *Cc:* Ramkumar Ramachandra; Peng Cheng; LLVMdev; Dale Martin > *Subject:* Re: [LLVMdev] Sporadic "RealOffset <= INT32_MAX && RealOffset > >= INT32_MIN" failures with MCJIT on Windows > > > On Fri, May 22, 2015 at 4:14 PM, Keno Fischer < > kfischer at college.harvard.edu> wrote: > >> This might be related to GOT relocations. I rewrote that part of >>...

...Engine/MCJIT/test-global-init-nonzero-remote.ll All of them fail with assertion: lli: /usr/local/google/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:230: void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry &, uint64_t, uint64_t, uint32_t, int64_t): Assertion `RealOffset <= (2147483647) && RealOffset >= (-2147483647-1)' failed. The reason is that AddressSanitizer replaces system malloc with its own allocator, which allocates memory at "unusual" parts of heap and the difference between pointers can be significant (and doesn't fit in...

...FAILED ******************** Script: -- /cygdrive/z/dev/llvm/x64/static/Release+Asserts/bin/lli -use-mcjit -mtriple=x86_64-unknown-cygwin-elf /cygdrive/z/dev/llvm/x64/llvm/test/ExecutionEngine/MCJIT/test-setcond-fp.ll > /dev/null -- Exit Code: 134 Command Output (stderr): -- assertion "RealOffset <= INT32_MAX && RealOffset >= INT32_MIN" failed: file "/cygdrive/z/dev/llvm/x64/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp", line 308, function: void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry&, uint64_t, uint64_t, uint3...

I''m trying to understand the Position object. Specially the various offset methods. From looking at the code I think I may understand them but I wanted to run it by the group to make sure I had a clear understanding. realOffset - This returns the coordinates of the element as if none of the elements on the page are scrollable from the document edge. cumulativeOffset - This returns the coordinates of the element from the document edge (not taking scrolling into account or anything fancy). positionedOffset - This will r...

...Release+Asserts/bin/lli -use-mcjit > -mtriple=x86_64-unknown-cygwin-elf > /cygdrive/z/dev/llvm/x64/llvm/test/ExecutionEngine/MCJIT/test-setcond-fp.ll > > /dev/null > -- > Exit Code: 134 > > Command Output (stderr): > -- > assertion "RealOffset <= INT32_MAX && RealOffset >= INT32_MIN" > failed: file > "/cygdrive/z/dev/llvm/x64/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp", > line 308, function: void > llvm::RuntimeDyldELF::resolveX86_64Relocation(const > llvm::Sect...

...pting to use LLVM in jitting mode for AMD64, we met a problem. When the jitted routine needs a big stack frame (> 1 page), the system attempts to call __chkstk to probe the stack. This attempt results in assertion in RuntimeDyldELF::resolveX86_64Relocation(), case ELF::R_X86_64_PC32, because the RealOffset does not fit in 32 bits. Same happens with __alloca (when IRBuilder::CreateAlloca appears in a conditional block). Perhaps the issue can be fixed by using indirect call via 64-bit register or replicating service routines inside jitted block. Is it known issue? Repro is available on demand, just l...

How difficult would it be to get the x and y coordinates returned of a draggable? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to

...64_t FinalAddress = Section.LoadAddress + Offset; + // The processRelocationRef method combines the symbol offset and the addend + // and in most cases that's what we want. For this relocation type, we need + // the raw addend, so we subtract the symbol offset to get it. + int64_t RealOffset = GOTAddr + Addend - SymOffset - FinalAddress; + assert(RealOffset <= INT32_MAX && RealOffset >= INT32_MIN); + int32_t TruncOffset = (RealOffset & 0xFFFFFFFF); + *Target = TruncOffset; + break; + } case ELF::R_X86_64_PC32: { // Get the placeholder value from t...

...ke into account the scroll offsets as shown below. Michael var Position = { ... clone: function(source, target) { source = $(source); target = $(target); target.style.position = ''absolute''; var offsets = this.cumulativeOffset(source); var scrolls = this.realOffset(source); // ### new target.style.top = (offsets[1] - scrolls[1]) + ''px''; target.style.left = (offsets[0] - scrolls[0]) + ''px''; target.style.width = source.offsetWidth + ''px''; target.style.height = source.offsetHeight + '...

I have two scrollable div''s (overflow:auto), one with a list of elements (the source) and the other is the drop target (dest). I''ve enabled ghosting so that the drag element gets out of the scrollable box (good). Interesting, at least on Firefox, the ghosted drag ends up going ''under'' the destination div when I drag it. No amount of z-order fidding seems to