gdb pretty print issue

[djblue]

I've noticed that sometimes when the gdb pretty printer calls jank_to_code_string it can return an odd looking string:

Locally, when I update the code to the following I don't have this issue anymore:

diff --git a/compiler+runtime/src/cpp/jank/c_api.cpp b/compiler+runtime/src/cpp/jank/c_api.cpp
index bd0524f74..ea8d28676 100644
--- a/compiler+runtime/src/cpp/jank/c_api.cpp
+++ b/compiler+runtime/src/cpp/jank/c_api.cpp
@@ -927,7 +927,7 @@ extern "C"
   char const *jank_to_code_string(jank_object_ref const o)
   {
     object_ref const o_obj(reinterpret_cast<object *>(o));
-    return o_obj.to_code_string().c_str();
+    return GC_strdup(o_obj.to_code_string().c_str());
   }
 
   static i64 to_integer_or_hash(object_ref const o)

Is there some subtle memory / ownership issue I am not understanding here? Should the pretty printer be wrapping the calls to jank_to_code_string with GC_strdup?

[jeaye]

Hm, gdb should only be able to print values on objects which are still alive. The strings generated from printing may be cleaned up, though, if the GC doesn't see that gdb is referencing them. So perhaps the gdb plugin needs to move those values out of GC land, by using a std::string or similar.

[kylc]

It looks like the returned char* is dangling, since the owned string it refers to, returned by to_code_string(), is cleaned up at the end of the call chain and before jank_to_code_string exits. Am I understanding correctly that since the code string is a regular jtl::immutable_string, not a jank object, there is no GC involvement here?

Here is a minimal repro:

user=> (let [s (cpp/jank_read_string_c #cpp "hello world")] (cpp/jank_to_code_string s))
"`ײ�q"

A regular strdup works where @djblue pointed out. The caller would be responsible for cleaning up the memory.

[jeaye]

It looks like the returned char* is dangling, since the owned string it refers to, returned by to_code_string(), is cleaned up at the end of the call chain and before jank_to_code_string exits. Am I understanding correctly that since the code string is a regular jtl::immutable_string, not a jank object, there is no GC involvement here?

jtl::immutable_string is stores its contents on the GC, which it uses for the additional performance benefit of substring sharing. However, if the string is large and owned, we will call GC_free on it in the dtor of immutable_string. So sharing is permitted, using the correct sharing mechanisms, but not just by grabbing .data() or .c_str() and hanging onto it. Also, if it's a short string, it'll be stored in-situ, so it'll also go out of scope when the immutable_string dies.

So, all in all, Kyle is right. We should be using strdup in the C API where we're returning C strings. The caller will then have the responsibility of freeing via free.