llvm dev - May 2015 - [LLVMdev] Sporadic "RealOffset <= INT32_MAX && RealOffset >= INT32_MIN" failures with MCJIT on Windows

So it appears that we get about half the crashes with the large code model.
The rest are crashing in the same way. It could either mean that large code
model still takes that crashing codepath and that the number of crashes
only went down by chance, or that in one place in the flow, large code
model is not matched to mean ELF::R_X86_64_PC64. I'm digging into this
issue further, but any hints along the way would be appreciated.

Thanks.

Ram

On Tue, May 19, 2015 at 12:06 PM, Reid Kleckner <rnk at google.com> wrote:
> That sounds like a PC-relative relocation failure. Usually this happens
> when the relocation target is more than 2 GB away from the source. Try
> using the large code model or tweaking the memory manager.
>
> It turns out it's surprisingly hard to portably allocate some memory
and
> then allocate some more within a 2 GB offset of the first allocation in a
> 64-bit process. For various reasons that I don't understand, reserving
2 GB
> of address space upfront and allocating from that is not workable for some
> MCJIT clients.
>
> On Tue, May 19, 2015 at 7:19 AM, Ramkumar Ramachandra <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
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150522/fbadc051/attachment.html>

This might be related to GOT relocations. I rewrote that part of
RuntimeDyldELFbecause I was seeing this issue. Have you tried trunk?

On Fri, May 22, 2015 at 5:10 PM, Ramkumar Ramachandra <artagnon at
gmail.com>
wrote:
> So it appears that we get about half the crashes with the large code
> model. The rest are crashing in the same way. It could either mean that
> large code model still takes that crashing codepath and that the number of
> crashes only went down by chance, or that in one place in the flow, large
> code model is not matched to mean ELF::R_X86_64_PC64. I'm digging into
this
> issue further, but any hints along the way would be appreciated.
>
> Thanks.
>
> Ram
>
> On Tue, May 19, 2015 at 12:06 PM, Reid Kleckner <rnk at google.com>
wrote:
>
>> That sounds like a PC-relative relocation failure. Usually this happens
>> when the relocation target is more than 2 GB away from the source. Try
>> using the large code model or tweaking the memory manager.
>>
>> It turns out it's surprisingly hard to portably allocate some
memory and
>> then allocate some more within a 2 GB offset of the first allocation in
a
>> 64-bit process. For various reasons that I don't understand,
reserving 2 GB
>> of address space upfront and allocating from that is not workable for
some
>> MCJIT clients.
>>
>> On Tue, May 19, 2015 at 7:19 AM, Ramkumar Ramachandra <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
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150522/476a9e14/attachment.html>

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
> RuntimeDyldELFbecause I was seeing this issue. Have you tried trunk?
>
I didn't notice that you were running 3.5 the first time I read this.
Keno's diagnosis is very likely to be correct. You should try trunk if
you're able to.

- Lang.

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
> RuntimeDyldELFbecause I was seeing this issue. Have you tried trunk?
>
> On Fri, May 22, 2015 at 5:10 PM, Ramkumar Ramachandra <artagnon at
gmail.com>
> wrote:
>
>> So it appears that we get about half the crashes with the large code
>> model. The rest are crashing in the same way. It could either mean that
>> large code model still takes that crashing codepath and that the number
of
>> crashes only went down by chance, or that in one place in the flow,
large
>> code model is not matched to mean ELF::R_X86_64_PC64. I'm digging
into this
>> issue further, but any hints along the way would be appreciated.
>>
>> Thanks.
>>
>> Ram
>>
>> On Tue, May 19, 2015 at 12:06 PM, Reid Kleckner <rnk at
google.com> wrote:
>>
>>> That sounds like a PC-relative relocation failure. Usually this
happens
>>> when the relocation target is more than 2 GB away from the source.
Try
>>> using the large code model or tweaking the memory manager.
>>>
>>> It turns out it's surprisingly hard to portably allocate some
memory and
>>> then allocate some more within a 2 GB offset of the first
allocation in a
>>> 64-bit process. For various reasons that I don't understand,
reserving 2 GB
>>> of address space upfront and allocating from that is not workable
for some
>>> MCJIT clients.
>>>
>>> On Tue, May 19, 2015 at 7:19 AM, Ramkumar Ramachandra <
>>> 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
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150522/d24652d0/attachment.html>