So I have somehow created schrödinger's cat in my program. If you observe what is happening, it works. But if you stop observing it, it starts corrupting.

If I put any print statement in it, it works. But if I have no print statements at all, it produces corrupted data. Doesn't matter what or when I'm printing.

I'm guessing its there's some fuckery going on with stdin/stdout and buffers. Even though the data coming to and from stdin/stdout should not affect the output.

I remember happening that to me once, it felt like it was witchcraft.

Are you creating variables specifically for debug printouts? In the case of a buffer overflow, they can act as buffer between data on the stack and "fix" data corruption due to a buffer overflow by "protecting" adjacent data.

Also see if removing optomizations wirh -O0 changes the behaviour

A single line of code, or memory access can greatly affect what data is where during actual runtime, even debug vs release runs are different. But in all cases it means one simple thing: your code is wrong.

if we're talking about corrupted data, this almost definitely means you're using a pointer that should no longer exist. Maybe you created it in a different scope in a method and that memory is reclaimed after the method is returned, or you deleted the underlying data of a pointer before you used it. But no matter the case, a well written, memory-leak free code will always behave deterministically.

Either go through your code line by line and figure out where the leak happens, or install something like Valgrind and let it check for you. Either way, good luck

congrats, you had created your 1st quantum program

@Hazarth I'm using Dart and indirectly JavaScript. Neither of which have pointers and both should be memory safe

@pythonPlusPlus Interesting. This definitely sounds like a memory leak to me. I've seen this behavior in C a couple of times before...

If your data is getting corrupted you *have* to be reading from something that wasn't meant to be read... It could be an encoding problem, but then again, how could printing to a console affect the encoding? That doesn't add up... hmm...

could you by any chance provide a snippet of the offending code, or do you have it public on github somewhere?

If it's not a memory access error, then there's no other option other than it being an encoding error... the print could do something in the stdout that would affect how the data is displayed, but not what the data is... which means the corruption should at least be constant and change with the data... if the corruption is random, it has to be memory related, but if it's constant, it has to be processing related, and most like encoding...

I'm curious now

Is anything asynchronous? Could be a race condition.

it's a data race probably, debugging sequences are tedious but very refined. Are you using threads or multi-producer queues (including any language native async task queue)?

The annoying thing about a data race is that it can't really be found and fixed with bisection or other common techniques. On the bright side, you get to eliminate tech debt and bill it as debugging.

As @lorentz and @lungdart mentioned, it's probably a race condition, when you add print/debug statements, it works without contention.
Pesky little buggers they are to deal with. I've mostly addressed them by redesigning the flow.