I have C-code translated in D that acts sometimes incorrect if the GC has made some collect. I would like to know why.

• Code runs correct if the GC collections are off
• There are no allocations within the C-translated-code except throw new (but they are not called)
• All allocations made in C-translated-code are still calloc/malloc `ed
• Even if I disable the GC before calling the function and just enable it after there will be an incorrect result
• Data passed to the function belongs to a struct and the function is called in a member function and is always correct

The main public function accepts a char* and returns a char*. Signature is like this:

char* fun(ref int, ref int, size_t, const char*, out int, out int, out int, uint);

Input paramter gets the pointer from char[] .ptr property (and length must be supplied too).

I didn't want to change the code much so I have some piece like that:

// const char *s2 = "!\"#$%&'()*+,-./:;<=>?@[\\]^_";
char* s2 = "!\"#$%&'()*+,-./:;<=>?@[\\]^_".dup.ptr;

Could this cause the issue? But the pointer is not used outside the function where it's created.

On Thursday, 16 September 2021 at 10:28:37 UTC, frame wrote:

char* fun(ref int, ref int, size_t, const char*, out int, out int, out int, uint);

// const char *s2 = "!\"#$%&'()*+,-./:;<=>?@[\\]^_";
char* s2 = "!\"#$%&'()*+,-./:;<=>?@[\\]^_".dup.ptr;

Use toStringz and not .ptr.

Or append \0 to your string.

On Thursday, 16 September 2021 at 10:48:19 UTC, bauss wrote:

char* fun(ref int, ref int, size_t, const char*, out int, out int, out int, uint);

// const char *s2 = "!\"#$%&'()*+,-./:;<=>?@[\\]^_";
char* s2 = "!\"#$%&'()*+,-./:;<=>?@[\\]^_".dup.ptr;

Also see the documentation for "toStringz" which has this:

Important Note: When passing a char* to a C function, and the C function keeps it around for any reason, make sure that you keep a reference to it in your D code. Otherwise, it may become invalid during a garbage collection cycle and cause a nasty bug when the C code tries to use it.

It probably should tell that somewhere else too.

On Thursday, 16 September 2021 at 10:48:19 UTC, bauss wrote:

Stupid me should really know that already, thanks =)
Of course I have dup'ed the \0 from the string away...

But still I don't know why it works if the GC is off?

On Thursday, 16 September 2021 at 11:06:04 UTC, frame wrote:

Did you see my second response?

On Thursday, 16 September 2021 at 11:11:56 UTC, bauss wrote:

Yes, but as I mentioned this pointer data isn't hold outside the function and the GC collect runs after data is processed, not in between. This pointer should be fully stack allocated and also newly generated each time the function is called, so I see no impact by the GC?

But GC collecting works now without issues.

On Thursday, 16 September 2021 at 11:35:27 UTC, frame wrote:

My guess is something is undefined behavior in the C code, idk really

On 9/16/21 6:28 AM, frame wrote:

...

// const char *s2 = "!\"#$%&'()*+,-./:;<=>?@[\\]^_";
char* s2 = "!\"#$%&'()*+,-./:;<=>?@[\\]^_".dup.ptr;

dup is a GC allocation. Are you using that in your C code? the GC might be collecting that string.

You are better off to cast away the immutable (as long as you are 100% sure the C code isn't writing to it), as the string literal will not be collected.

-Steve

On Thursday, 16 September 2021 at 15:34:25 UTC, Steven Schveighoffer wrote:

The compiler doesn't show that lines with -vgc. Maybe it knows that it is only stack allocated?

Technically, the GC could collect that data if it wants - it's not longer used after the function returns. At least I control that the GC cannot collect it till my data is processed, so there should be no problem.

I guess the C-methods did corrupt the memory which the compiler has reserved for that function data statically and then the GC collect marks it as free or some other UB.

Yes, I changed it to stringz and a cast and the problem is gone so far. All char* are read only in the function or passed to stdlib functions that should not modify it.

On 9/16/21 1:08 PM, frame wrote:

Are you sure? Be very pedantic about what C functions do with the data you send it. Sometimes they store it somewhere to use later. Sometimes they expect it to be allocated by the C heap, etc.

Without seeing how you use it, I can't tell you if it's wrong or not.

If it's a literal, you don't need to toStringz (which also allocates). All string literals are zero-terminated (and actually implicitly castable to immutable char *).

-Steve