Closed clavin-xlnx closed 3 years ago
Thanks for the report.
We should catch this problem sooner and present a better error to the user.
We could in theory support allocations this large (between 2^31 and 2^32 bytes), but it would be nontrivial, because an individual java.nio.ByteBuffer
can store at most 2^31 bytes. We would need to add an extra layer of indirection, and it would only buy us a factor of 2 in supported allocation size, because the capnproto format does not support allocations larger than 2^32 bytes.
Is there a way you can split up your message so that it does not need to contiguously allocate such a big chunk of memory?
d310db1e8895cbc4d65d5e7cfef7cdcbfa21edd1 should prevent the overflow and throw a better exception.
Thanks for the overflow check, I've confirmed it throws correctly for our situation. We'll try changing how the data is being stored to avoid such a large singular array.
Closing, because the overflow has been fixed.
Thanks for the rapid fixes on the previous issues (#97 and #99). We've encountered another integer overflow situation in Xilinx/RapidWright#176 when the
BuilderArena
attempts to allocate a newByteBuffer
, in our setup, we get the following stack trace:BuilderArena.allocate()
is called with amount=346319666, however on line 101, this is multiplied by Constants.BYTES_PER_WORD=8, causing it to overflowInteger.MAX_VALUE
.