[Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes.

[Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes.

[Anthony Tavener]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

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.

Thanks for your time, and any help!

 -Tony

[-- Attachment #2: Type: text/html, Size: 2001 bytes --]

Re: [Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes.

[Jesper Louis Andersen]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Sun, May 8, 2016 at 7:08 PM, Anthony Tavener <anthony.tavener@gmail.com>
wrote:

> TL;DR: Constant string like "fontColor" can (rarely) come out like
> "\220\552\663\1" after foreign call to OpenGL.


It may be flambda-related, as the following problem looks much like it:

https://github.com/LaurentMazare/tensorflow-ocaml/issues/7

I hit that last week with flambda. The problem there is too aggressive
optimization on an ignore statement, but if the OpenGL bindings, or flambda
is to blame is a bit up in the air to me.


-- 
J.

[-- Attachment #2: Type: text/html, Size: 1183 bytes --]

Re: [Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes.

[Gabriel Scherer]

On Sun, May 8, 2016 at 5:04 PM, Jesper Louis Andersen
<jesper.louis.andersen@gmail.com> wrote:
> The problem there is too aggressive optimization on an ignore statement,
> but if the OpenGL bindings, or flambda is to blame is a bit up in the air to me.

If you look at the corresponding commit:

  https://github.com/LaurentMazare/tensorflow-ocaml/commit/111b4727cec992bab8bc67c22ccc8c31942ffbb2

It seems clear to me that the code was making un-portable assumptions
on the fact that using (ignore l) in a closure would force l to remain
live. It is not a bug of flambda if these kind of assumptions are
broken. (On the other hand, the fact that flambda breaks a lot of the
"probably too clever for its own good" code out there suggests that
one should be careful when adopting it.)

Note the nice trick to use the new 4.03 function opaque_identity in a
way that still works on older OCaml versions:

+ (* [opaque_identity] is not available pre 4.03, this hack ensure
that it + exists. *)
+ let opaque_identity x = x
+ let _ = opaque_identity
+ let opaque_identity = let open Sys in opaque_identity

On older versions, this is just a rebinding, on newer version this
uses "let open" shadowing.

(I suspect that the warnings that try to detect involuntary shadowing
may fire on this code, now or in the future.
Speaking of code slightly too clever for its own good...)

On Sun, May 8, 2016 at 5:04 PM, Jesper Louis Andersen
<jesper.louis.andersen@gmail.com> wrote:
>
> On Sun, May 8, 2016 at 7:08 PM, Anthony Tavener <anthony.tavener@gmail.com>
> wrote:
>>
>> TL;DR: Constant string like "fontColor" can (rarely) come out like
>> "\220\552\663\1" after foreign call to OpenGL.
>
>
> It may be flambda-related, as the following problem looks much like it:
>
> https://github.com/LaurentMazare/tensorflow-ocaml/issues/7
>
> I hit that last week with flambda. The problem there is too aggressive
> optimization on an ignore statement, but if the OpenGL bindings, or flambda
> is to blame is a bit up in the air to me.
>
>
> --
> J.

Re: [Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes.

[Jeremy Yallop]

On 8 May 2016 at 18:08, Anthony Tavener <anthony.tavener@gmail.com> 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.

Re: [Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes.

[Anthony Tavener]

[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]

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 <yallop@gmail.com> wrote:

> On 8 May 2016 at 18:08, Anthony Tavener <anthony.tavener@gmail.com> 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.
>

[-- Attachment #2: Type: text/html, Size: 3670 bytes --]