Subj : Compiling from source
To   : tenser
From : Oli
Date : Tue Jan 26 2021 16:43:09

tenser wrote (2021-01-27):

 t> On 26 Jan 2021 at 09:21p, Avon pondered and said...
 Av>> free(): double free detected in tcache 2
 Av>> Aborted

 t> Sorry, I haven't been keeping up here, but this is a bug
 t> in that software: the code is simply mismanaging memory.
 t> The solution here is to find the bug and fix it; sadly,
 t> much of this stuff is an unmaintained mess....  But trying
 t> a 32-bit build won't fix it, as was suggested earlier.

yes, these are separate issues, but building as 32-bit worked around some other issues.

 t> Well, a thing to try is to build it with one of the memory
 t> sanitizers turned on and see if you can find the location
 t> of the first free and the second; simply nil'ing out the pointer
 t> will likely move past _that_ problem, as free(NULL) is a no-op.

I couldn't see anything obvious in the spoon code. I found some examples for building with the sanitizer turned on. Would something like this work:

g++ spoon.cpp ... -o spoon -ggdb -fsanitize=address -fno-omit-frame-pointer

or a longer version (not sure if the libs are needed):

g++ spoon.cpp ... -o spoon -ggdb -fsanitize=address -fno-omit-frame-pointer -static-libstdc++ -static-libasan -lrt

 t> But a more general problem is that none of this stuff was written
 t> to be memory safe; short of a substantial refactoring of the
 t> code, I suspect things like this will keep cropping up.

Rewrite everything in Go?

---
 * Origin: . (21:3/102)

.