bytedeco/javacpp

The pop_back() for vector and deque as generated by javacpp always returns a dangling reference for anything other than a primitive type. public Widget pop_back() { long size = size(); Widget value = get(size - 1); // @ByRef alias to &vec[size-1] resize(size - 1); // destroys vec[size-1] -> ~Widget() runs return value; // dangling: element already destroyed } For a T with a non-trivial destructor (e.g. PIMPL freeing a unique_ptr), the returned peer is dangling the instant pop_back() returns. Any use is a use-after-free. (The accessors get(i)/front()/back() are fine: their alias is valid at return and only dangles on later mutation, per #672. pop_back() is the only method that mutates its own referent before returning it.) Reproduce (see attached jcpp-popback-repro/) Widget owns a heap pointer; its destructor frees and nulls it. Any call on a widget after that is a use-after-free. In the reproduction, ~Widget() also sets the handle it h

Hello! I'm investigating a memory leak at generated code caused by the VectorAdapter<P> template. In my case, the memory leak is several megabytes per second, so it visible. Heap and others JVM memory areas remains the same size. Valgrind reports memory leak at the JNI code. The root cause is: Allocated raw void* memory area at operator VectorAdapter<P>::P*() will be freed at VectorAdapter::deallocate(void*), but constructed-in-place P objects by std::uninitialized_copy never destructed, which cause a memory leaks at some situations. To achive that, P object should contain some dynamically allocated object (std::vector<..> in my case). Example: // Some C++ API interface which I want to use class SomeClass { ... public: // Generated by JavaCPP: public native @StdVector LeakedClass getResults(); std::vector<LeakedClass> getResults(); }; // Class which destructor never called class LeakedClass { public: // Non-default constructor LeakedClass(const uint64_t a, const uint64