Matt Corallo [Wed, 8 Mar 2023 05:04:14 +0000 (05:04 +0000)]
[Java] Expose the ProbabilisticScorer from the CMC correctly
We'd previously exposed a race-y version of the ProbabilisticScorer
where its held within a lock but also made public with no threading
requirements placed on it.
This resolves that issue by exposing it via a wrapper that holds
the score lock.
Matt Corallo [Wed, 8 Mar 2023 01:06:31 +0000 (01:06 +0000)]
[Java] Update tests to latest (0.0.114) LDK API, rm non-hu ones
The old non-human-object-based tests don't really have any
business being held on to, so we simply remove them entirely here,
relying on the `HumanObjectPeerTest` to do all our work.
Matt Corallo [Wed, 8 Mar 2023 01:58:42 +0000 (01:58 +0000)]
Ensure enums generate a ref in owning structs
Previously we only added a ref in an owning struct to an enum if
that enum contained a trait in a field. This isn't sufficient as an
enum could still contain a reference to an opaque object, which
needs to stick around as long as the enum exists.
For simplicity, simply add a ref in all cases as it seems to still
work in our own internal tests.
Matt Corallo [Tue, 8 Nov 2022 23:48:07 +0000 (23:48 +0000)]
Only set up `NioPeerHandler` after chain sync completes
No peer connections must be made until after `chain_sync_complete`
is called when using the `ChannelManagerConstructor`, so
initializing the `NioPeerHandler` before then just tempts fate and
risks doing Bad Things.
Matt Corallo [Mon, 3 Oct 2022 20:07:28 +0000 (20:07 +0000)]
[TS] Fix generation for traits that have supertraits
When we have a trait with a supertrait, we have to pass both the
main- and super-trait instance indxes through to C so that it can
call both. We failed to do this, missing an argument entirely when
calling the C code.
Instead of trying to allocate a new instance index, we opt to store
instance indexes in trait structs (assuming there is one) and then
reuse the one in the constructed object.
Matt Corallo [Sat, 3 Sep 2022 20:24:10 +0000 (20:24 +0000)]
[TS+Java] Ensure we don't try to add a reference from `null`.
At least in `Event::PaymentPathFailed` if we try to map an event
with no `retry` we'll hit a `NullPointerException` as we'll try to
add a reference from the `null` retry back to the `Event` itself.
The simple fix is to simply exhaustively check for `null` before
adding references everywhere.
Matt Corallo [Sat, 13 Aug 2022 01:34:03 +0000 (01:34 +0000)]
Drop clone on tuple-field-fetching
Early in the lifetime of the bindings here tuple-field-fetching
had memory tracking issues which appear to have been solved now.
Thus, we can go ahead and drop the clone, at least for has-inner
types.
Matt Corallo [Fri, 12 Aug 2022 23:08:17 +0000 (23:08 +0000)]
Switch 32-bit platforms to using 64-bit "pointers"
This much more cleanly fixes the issue described in the previous
commit by simply using 64-bit integers to represent pointers on
32-bit platforms, letting us store the required flag bit in the top
32-bits that are always free.
It does, however, imply changing the entire call semantics for
TypeScript to use BigInts for pointers, rather than numbers.
Matt Corallo [Thu, 11 Aug 2022 21:38:05 +0000 (21:38 +0000)]
Change where the opaque struct is_owned bit is stored in pointers
When we're returning a reference to an opaque struct, we previously
used the LSB to track the is_owned bit. This works for
heap-allocated structs just fine as `malloc` guarantees maximal
(usually 8-byte) alignment for all returned pointers. However, for
opaque structs which are actually a reference to a field in a
larger native Rust struct (eg `NodeId` in
`ChannelDetails_get_node_one`), this may not be the case. This
caused reading off-by-one `NodeId`s.
We fix this by adding a new set of utilities which handle tagging
and un-tagging pointers which are a bit more complicated. One
32-bit platforms, we simply use the low bit but will change that
in the next commit. However, on 64-bit platforms we have to be a
bit more careful. Modern 64-bit platforms, including Android, use
the top bits (8 bits in the case of android) for pointer
authentication. x86_64 sets the top 16 bits to the same value, but
they may be 1s or 0s. Thus, we use (9th bit) ^ (10th bit) as our
tag, assuming that they are always equal.
This isn't the most robust solution, but until there's time to
rewrite all the opaque object handling to fetch java fields from C
this is likely the best we're going to be able to do.
projects / ldk-java / log