Update

Address comments

Remove leftover print

So I test with clang 8, clang 8 and gcc 9 and I cannot repro. This suggest that this is a problem with the CI and that it should be fixed there - or that there is something the CI is doing that we are not, in which case we also need to know.

Well, what's the log of the bitcoind process? Why did it exit?

This still doesn't say what the problem is.

Can you provide a reason in the description?

Why?

Remove unecesary include

There is still no finalizer for that class unless I messed it, which means context will be leaked when things are garbage collected.

If libevent needs ws2_32 on some plateform, then it needs it on some plateforms. This needs to be part of the fix. I don't see how any backport changes this.

Test plan is inadequate.

Event requires lib ws2_32 on windows

The test plan is inadequate.

This is obviously wrong. The fact that it happens to work doesn't make it right.

Theres also fixing cloneContext, which IMO should result in returning a new NativeSecp256k1 class with the cloned native lib context in, but i was hoping to fix that on another ticket.

Looks like there is some duplication with the test runner.

This is leaking. Note that it was already leaking, indeed, but because everything was static, the application would just leak one context and voila. Now it can leak n contexts, and this is bad. There is also a problem of error management when the context is created or used. This also is preexisting, but one can assume that creating one context at program startup is less likely to fail (for instance due to OOM) than when the java app is up and runnign and eating 16GB of RAM, like all self respecting java apps do.

Well then, if it is a build type, then it is a build type, no? Not an option.

Maybe you want to check buster-backports

The getContext used to have the benefit of checking that the context is properly initialized. Now there is no such check, so if cleanup is called, then something else is, you'll get an horrible crash instead. I do not think this is somethign java devs expect.

You really want to think that ban behavior through.

There are some improvements you can d here, but overall it's good.

Add new line