Potential FFI Problems #1
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I don't know whether this is helpful or not, but I asked Codex to look at potential problems.
Yes, there are binding-level issues that could plausibly cause memory corruption.
libFLACinit signature likely wrong (high risk ABI mismatch)In
libflac-ffi.rkt,FLAC__stream_decoder_init_fileis bound with 5 args.Current FLAC C API uses a 6th
client_datapointer. If your installedlibFLACexpects that, this is an ABI mismatch.TagLib complex-property pointer depth looks wrong (high risk)
Your own comment shows
TagLib_Complex_Property_Attribute***, but binding uses a single pointer type intaglib-ffi.rktand function defs at lines 236/239/244.If the real API is triple-pointer here, this can definitely corrupt memory.
ao_shutdownreturn type is incorrectIn
libao-ffi.rkt, comment saysvoid ao_shutdown();but binding is-> _intat line 71.Usually this won’t always crash, but it is still an incorrect ABI declaration.
Potential lifetime issue in picture extraction path
In
taglib-ffi.rkt, bytes are produced from a pointer, thentaglib_complex_property_freeis called at line 279.This is only safe if that
castmakes a full copy; if not, it becomes use-after-free.This is indeed correct, I hopefully corrected this.
I corrected this.
This is not really a problem as this is treated purely as a pointer handle to call api functions of tagLib.
castwill make a copy that can be garbage collected.Although 1. and 3. were bugs, I don't see them as relevant for the problem you were seeing with memory corruption.
I noticed that you said the error only appears on Linux, not on Windows.
That might be hint for someone know more about the FFI.
I've run the
play-test.rktprogram, in racket, and it does not generate this problem.I'll test my more complex rktplayer program (which also uses a gui).
FWIW - here is a new list of potential problems.
Here 2. and 4. are the same as before.
Yes. I still see several plausible FFI-boundary problems:
Likely use-after-free in FLAC callbacks (high risk)
In
libflac-ffi.rkt,write-callbackstores rawframe/bufferpointers intowrite-data;meta-callbackstoresmetapointers at line 501.Those pointers are consumed later (
process-write-data/process-meta-data), outside the callback frame. If libFLAC only guarantees validity during callback, this is classic memory corruption territory.TagLib complex-property pointer depth still suspicious (high risk)
taglib-ffi.rktbindstaglib_complex_property_getas a single pointer, but the nearby C comment saysTagLib_Complex_Property_Attribute***.If the real ABI is triple-indirection, this remains an incorrect binding and can corrupt memory.
Possible null-pointer call into TagLib (medium risk)
In
taglib.rkt, result oftaglib_file_newis used immediately intaglib_file_is_valid(line 70) without null check.If creation fails and returns null, behavior depends on TagLib internals; this can crash.
Ownership/lifetime mismatch in TagLib picture extraction path (medium risk)
taglib-ffi.rktcasts picture data to bytes, then frees complex properties at line 279.This is safe only if
castperforms an eager copy. If not, it is use-after-free.It was a ao problem. Too many closing of ao-device handles. A finalizer that worked on a wrong administration on progam exit.
This is probably true, given the documentation of libFLAC, although I've not seen problems here, maybe because I'm using very little functionality of the library. For complex metadata, I'm using libtag.
That could be true, but is unlikely to happen. I'll fix it though.