-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix CString use-after-free bugs and memory leaks #13
Conversation
`useAsCString` frees the CString after the IO action finishes executing, so passing `return` as that action can never be correct. To make sure the CString gets freed at the right time, we need a “with”-style abstraction, not just a conversion function. While we’re here replace this with `withCStringLen`, which also makes fewer copies. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
The renderer functions return a malloc’d string which the caller is expected to free. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Excellent, thanks. |
@jgm Thanks so much for the ping! New release made. |
@andersk compiling pandoc with the new version, I'm seeing some odd test results which look like they might be due to badly handled CStrings:
Note the randomly inserted letters. |
Here are some interactive runs showing the nondeterministic output:
Similar results with subscript:
Note that super/subscript in commonmark output is not supported directly by cmark; pandoc's CommonMark writer handles this by inserting TEXT Nodes into the node tree that cmark converts to commonmark. It's baffling to me why we're not seeing these issues elsewhere, though, since we do the same thing, for example, in processing each Space! |
Aha! I've reproduced the issue just using cmark-gfm (with the patch in this PR):
|
Moving discussion to new issue #14. |
Since NUL-terminated CString is much more common in foreign APIs than CStringLen, one should not have to manually build these functions out of `peekCStringLen`, `withCStringLen` (and perhaps get it wrong, like I did in jgm/cmark-hs#13). While here, document that `peekCStringLen`, `withCStringLen` are O(n) as well. Fixes haskell#32. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Since NUL-terminated CString is much more common in foreign APIs than CStringLen, one should not have to manually build these functions out of `peekCStringLen`, `withCStringLen` (and perhaps get it wrong, like I did in jgm/cmark-hs#13). While here, document that `peekCStringLen`, `withCStringLen` are O(n) as well. Fixes haskell#32. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Since NUL-terminated CString is much more common in foreign APIs than CStringLen, one should not have to manually build these functions out of `peekCStringLen`, `withCStringLen` (and perhaps get it wrong, like I did in jgm/cmark-hs#13). While here, document that `withCStringLen` is O(n) as well. Fixes haskell#32. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
useAsCString
frees theCString
after theIO
action finishes executing, so passingreturn
as that action can never be correct. To make sure theCString
gets freed at the right time, we need a “with”-style abstraction, not just a conversion function. While we’re here replace this withwithCStringLen
, which also makes fewer copies.The
renderer
functions return amalloc
’d string which the caller is expected tofree
.