Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Change back to getLong: why ?

See original GitHub issue

Hi to all,

This is more a clarification request than an issue per se:

we’re currently evaluating lmbdjava and while we didn’t experience any problem on OS X and Linux, we had some random and rather frequent crashes on Windows (access violations while retrieving buffers or keys). After investigation, we couldn’t really pinpoint anything wrong with our code or discern any general rule as to the crashes’ cause (multithreading, memory, etc.). We’re using JDK 8 but using other JDKs did not help.
we finally managed to reproduce the problem consistently using ByteBufferProxy.PROXY_SAFE, creating a large env size (> 1Gb) and a bit of our code in a JUnit set to 2048m max heap size (letting the default buffer, PROXY_OPTIMAL, makes it much harder to crash, but it crashes eventually – the same with Agrona buffers or even byte arrays). Our piece of code does not really stress lmdb, nor fills the map or anything extreme.
then I saw issue 97 and your change from getLong to getAddress in the buffer proxies, and decided to give it another go. It improved things a lot. Early tests seem to indicate that the problem went away, at least with ByteBufferProxy.PROXY_SAFE.

Which leads to my question:

since we originally had the problem with OPTIMAL proxy versions and you reverted back to using getLong for these, the problem is still there unless we write our own proxy. Which we can do, of course, but I wanted to know if there was a specific issue that made you revert your changes?

Thanks!