I have been trying to find the reason for this issue for days, and can't seem to find it. Perhaps something stupidly easy I am simply missing? I don't know.
The problem is, that I am unable to reproduce the error in a small example. I only encounter this problem in a bigger project, that I cannot share publicly in its entirety.
I encounter more and more problems with funcs and procs, that worked for 6 to 24 months up until recently. Changing to an older Nim version, did not help, though.
The aforementioned funcs and procs are all related to doing String operations. For example, adding characters to a string, or transforming the string in different ways. I did not see a clear pattern in what is causing the error. The only 2 things those operations have in common is that they deal pretty often (by far not always) with low-level cstring instances and it's most of the time related to strings coming in some shape or form from the Windows API (through winim), even though, they are converted to plain old Nim strings. However, the cstrings are supposedly not nil, as I can see them most of the time in the log through an echo, right before the segmentation fault occurs. To my knowledge, according to what Nim is telling me, the string are supposedly properly used and converted to Nim types.
Every single segmentation fault is essentially triggered in this exact place: https://github.com/nim-lang/Nim/blob/8d2f6bba3a491bc93677da9590397346e63c2bb2/lib/system/alloc.nim#L716
No matter what type of string operation is done, whether it's modifying something or creating an entirely new string or just copying it or whatever, the segmentation fault always happens at this exact line.
It would be highly appreciated, if anyone could give me a hint or lead me in the direction of a solution for this big issue.
Using cstring is an unsafe operation that yields a view of a Nim string.
If your string gets deallocated while you hold a string view of it you will get a segmentation fault.
To proceed from there, review carefully the code using the cstring; even if the stacktrace in the segfault doesn't point to it, there is 99.99% change your segfault occurs during bad segfault manipulation.
I would bet that it is not a Nim problem, but related to your wrong casts or a winnim issue.
Try compiling with --gc:arc to see the difference.
Then try --gc:arc -d:useMalloc and run it with valgrind.
Maybe that gives you more informations.
Every single segmentation fault is essentially triggered in this exact place: https://github.com/nim-lang/Nim/blob/8d2f6bba3a491bc93677da9590397346e63c2bb2/lib/system/alloc.nim#L716
that sounds a lot like a heap corruption. So it's probably either some code wrtinig more into a cstring than allocated or a cstring is still being used after being freed.
Thanks a lot to everyone for these very helpful replies. :) I will investigate all cstring usages extremely carefully and will try to avoid juggling with (c)strings.
I'll keep this thread updated.
Thank you!!
I'm back with good results.
First of all, thank you all very much! You really helped a lot.
I combined the suggestion given to me, then debugged the crap out of the program and now it runs as it should!
Comparing Nim 1.5.1 a.k.a. current development version of Nim to Nim 1.4.8 a.k.a. current stable version of Nim is like comparing night and day. Not sure, if there was actually a compiler bug relevant to this thread's issue, but as soon as I switched to the newest devel version, some errors already went away. Then, I got indeed a warning for a single implicit conversion to cstring. I fixed that, then fixed the casting around with it and most issues were fixed. The other issues became a piece of cake, once this big issue was resolved.
As @Stefan_Salewski suggested, I initially added the compiler switches --gc:arc -d:useMalloc to the process and that indeed helped in finding the cstring issue mentioned above.
After all that, I decided to stay with --gc:arc and so far it doesn't seem to create any issues, that I could notice.
Well, I cannot thank you enough!
I am loving Nim and its community more every single day!
THANK YOU!