Why does moving around ios_base::sync_with_stdio(false), cin.tie(NULL) result in a memory error?

Question

I was solving a competitive programming task when I made a bug. I placed ios_base::sync_with_stdio(false), cin.tie(NULL) into solve() instead of main().

#include <bits/stdc++.h>
using namespace std;

void solve(){
    ios_base::sync_with_stdio(false), cin.tie(NULL);
    // implementation not important
}

int main() {
    int t;
    cin >> t;
    while(t--)
        solve();
}

This resulted in a memory error. However when I move it into the main() I pass with no issues:

#include <bits/stdc++.h>
using namespace std;

void solve(){
    // implementation not important
}

int main() {
    ios_base::sync_with_stdio(false), cin.tie(NULL);
    int t;
    cin >> t;
    while(t--)
        solve();
}

My understanding from this answer is that this disables the synchronization between C and C++ streams, and then unties cin and cout. Especially since I'm only using cin / cout, why does moving that line around cause such a drastic difference?

(in case you want the actual source)

Memory error submission

Passing submission

Answer 1

From [ios.members.static]/2:

Effects: If any input or output operation has occurred using the standard streams prior to the call, the effect is implementation-defined. Otherwise, called with a false argument, it allows the standard streams to operate independently of the standard C streams.

Furthermore, the cppreference page notes that

If this function is called after I/O has occurred on the standard stream, the behavior is implementation-defined: implementations range from no effect to destroying the read buffer.

I'm not entirely sure what exactly happened in your case. Reading the source of libstdc++ (e.g., here), which I assume is the standard library being used, it seems that it clears the buffers. This means that it's possible that some input you were waiting for was buffered, and your program either started reading from a strange spot or the reads just failed entirely. But the precise details and why that would have caused an out of memory error is beyond me.

(It's also worth noting that the fact you're calling it in a loop doesn't seem to be the problem in this implementation, as libstdc++ only clears the buffers if you're already unsynchronised with stdio.)