Some sequence of chars from 0-74 seems to escape print buffer and corrupt squiggly line error popup

[KSSAB]

Edit: Had a bit of arithmetic error, 'a' is being divided by 2 first and the upper bound is actually 74, so it is some combination of characters from 0-74 : https://godbolt.org/z/sc411Gbas ;

I think this is pretty close to minimal example: https://godbolt.org/z/5o9KoKdMo

The following program generates 200 * 200 random chars from 0-'z'-('a' / 2): https://godbolt.org/z/Mb1G9Y7GT, it seems to compile and execute without error, but following execution I get a red squiggly line under the declaration for the uniform int distribution and include for array (line 9 and line 1 respectively):

https://i.imgur.com/1vH4HpG.png

https://i.imgur.com/asj598Z.png

Even when the location of char storage is heap allocated the issue persists: https://godbolt.org/z/Pb1K8Ebdr

Changing the seed appears to affect how the corruption occurs:

https://godbolt.org/z/rKMM6vTKM

https://godbolt.org/z/ezPa93v45

I would suspect as the corruption occurs differently with different seeds it is not an overflow (or at least not directly) but rather some sequence of characters escaping or not being properly sanitized.

Apologies if this is expected behavior

Edit:

One additional matter, std::flush does not prevent the behavior : https://godbolt.org/z/597645Pj5

But interspersed newline does , even with 2000*2000 characters : https://godbolt.org/z/eT8MGhWca ,

I think this lends credence to the notion it is a sanitizing issue

[AbrilRBS]

Hi, thanks for reporting the issue!

The good news is that this is not any type of corruption (Which would have been interesting to debug!), but rather a flaky regular expresion and/or that said regular expresion is being used where it's not supposed to be:

We try to find output of the form 'filename:line', and one of the regular expressions, namely https://github.com/compiler-explorer/compiler-explorer/blob/main/lib/utils.ts#L95 matches with strings such as D(4 (See https://godbolt.org/z/56nhM1P8r), which is clearly not intended, which we should fix!

Also, if you try to reproduce this in the output pane of a compiler asked to execute the code, you can see that this does not happen (https://godbolt.org/z/Wzj5KKocT). This is only because in the output pane we don't link back to the source code (even if we do have to info to do so as in the execution pane). Maybe this is something that we should be doing for the executor pane too. (Or maybe the other way around and the output pane should be able to link back to the source code. Who knows!) I'll think about what the better fix is and let you know as soon as it's implemented.

Again, thank you so much for taking the time to report the issue and specially investigating it, you saved me lots of time :)