From: Jeremy Yallop <yallop@gmail.com>
To: Anthony Tavener <anthony.tavener@gmail.com>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes.
Date: Mon, 9 May 2016 05:52:22 +0100 [thread overview]
Message-ID: <CAAxsn=GPb_9w_FnaYs03oK-Y_ZFB0SghR-ATsYXVyaF0HZ0YXQ@mail.gmail.com> (raw)
In-Reply-To: <CAN=ouMTGAY1P9FTL9Mg-foWG1K5bHVW_i3HOp+SySTeK8SsTog@mail.gmail.com>
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.
next prev parent reply other threads:[~2016-05-09 4:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-08 17:08 Anthony Tavener
2016-05-08 21:04 ` Jesper Louis Andersen
2016-05-08 22:52 ` Gabriel Scherer
2016-05-09 4:52 ` Jeremy Yallop [this message]
2016-05-09 5:32 ` Anthony Tavener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAxsn=GPb_9w_FnaYs03oK-Y_ZFB0SghR-ATsYXVyaF0HZ0YXQ@mail.gmail.com' \
--to=yallop@gmail.com \
--cc=anthony.tavener@gmail.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).