I just tried 4.03.0 (no flambda), recompiling all, and the problem still occurs. (And thanks to opam and a fast compiler, this process was quick and easy!) Jesper, those numbers coming through in that problem do look similar. Anyone know what they are? They strike me as familiar, but I can't place it: looks like escaped octal triplets, with occasional letter and terminated by some low-valued marker (\1,\2) -- and it's a proper string, not like random memory. Gabriel, I am perfectly happy with getting bitten by "clever code", due to a smarter compiler -- well, provided there's a way to express what's wanted. :) Jeremy, I will try to reduce this to a simpler case with just tgls/opengl, and see if I can trap the flawed cases, or make it easily reproducible. Right now I have to head out to work though. Thanks for the input, guys! On Sun, May 8, 2016 at 10:52 PM, Jeremy Yallop wrote: > On 8 May 2016 at 18:08, Anthony Tavener wrote: > > TL;DR: Constant string like "fontColor" can (rarely) come out like > > "\220\552\663\1" after foreign call to OpenGL. > > > > I was seeing glitches in render output, and have tracked it down to > "uniform > > variable names" which are given as constant strings, but on OpenGL side > they > > can appear malformed. > > > > OCaml call: > > > > let color = Gl.get_uniform_location sp "fontColor" in > > > > In a trace of the OpenGL calls from the running program the result is > > usually like this: > > > > glGetUniformLocation(program = 3, name = "fontColor") = 3 > > > > But on occasion (once in several hundred calls) has garbage: > > > > glGetUniformLocation(program = 3, name = "\220\552\663\1") = -1 > > > > The really odd thing to me is the structure of these strings (some more, > not > > all from "fontColor"): > > "\220 \774\1" > > "\220\332\663\1" > > "\440\\\665\1" > > "\220\552\663\1" > > "\220J\663\1" > > "\660\117\553\2" > > "\440\220w\2" > > > > For reference, Gl.get_uniform_location is implemented thusly (in tgls): > > > > let get_uniform_location = > > foreign ~stub "glGetUniformLocation" > > (int_as_uint @-> string @-> returning int) > > > > > > I am using OCaml 4.03+flambda. The problem occurs with -O3 or no > > optimizations. The problem might have happened with prior versions (I > > haven't been able to work with OCaml much in the past year), and my own > code > > is of course suspect. :) > > > > I'm posting in case this rings a bell for someone, that they might know > > what's going on. I'm continuing to debug. > > If you have a reproducible test-case I'd be interested to take a look at > this. >