From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 44D947EE88 for ; Mon, 9 May 2016 07:32:48 +0200 (CEST) IronPort-PHdr: 9a23:a7Y4zRTetr4/QErYGV8GgKePHNpsv+yvbD5Q0YIujvd0So/mwa64bBWN2/xhgRfzUJnB7Loc0qyN4/GmADVLscvJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbviqtuKOk4Y2XKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGY2zRakzTKRZATI6KCh1oZSz7ViQBTeIs1kRSGgTg1J5CgzB6wmyCob4ti/9rsJy3SCbOYv9SrViChq46KI+YRn0iCABJnYF+X/ajMFqxPZSpg6hoBpuhZLdfoyTOeBWcabUfNdcTm1ECJUCHxddC5+xOtNcR9EKOvxV+syk/wMD Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=anthony.tavener@gmail.com; spf=Pass smtp.mailfrom=anthony.tavener@gmail.com; spf=None smtp.helo=postmaster@mail-wm0-f46.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=74.125.82.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of anthony.tavener@gmail.com designates 74.125.82.46 as permitted sender) identity=mailfrom; client-ip=74.125.82.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wm0-f46.google.com) identity=helo; client-ip=74.125.82.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-wm0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASAQD5HzBXjy5SfUpehHsPBrQJhniGEAKBHgc7EQEBAQEBAQEBEQEBAQEHCwsJIS+CLYIUAQEBAwESEQQZARsdAQMBCwYDAgsNKgICIQEBEQEFARwGEwgah3IBAwsIkFCPQoExPjGLO4FqgliGWgoZJw1Sg2sBAQEBAQEBAwEBAQEBARQBBQoFhhGETIJDhHyCWQEEjV50iR8xgVWKToF5jxeHWIYlEh6BDjaCJB6BdB0yiQYBAQE X-IPAS-Result: A0ASAQD5HzBXjy5SfUpehHsPBrQJhniGEAKBHgc7EQEBAQEBAQEBEQEBAQEHCwsJIS+CLYIUAQEBAwESEQQZARsdAQMBCwYDAgsNKgICIQEBEQEFARwGEwgah3IBAwsIkFCPQoExPjGLO4FqgliGWgoZJw1Sg2sBAQEBAQEBAwEBAQEBARQBBQoFhhGETIJDhHyCWQEEjV50iR8xgVWKToF5jxeHWIYlEh6BDjaCJB6BdB0yiQYBAQE X-IronPort-AV: E=Sophos;i="5.24,599,1454972400"; d="scan'208,217";a="177033998" Received: from mail-wm0-f46.google.com ([74.125.82.46]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 09 May 2016 07:32:47 +0200 Received: by mail-wm0-f46.google.com with SMTP id a17so166318847wme.0 for ; Sun, 08 May 2016 22:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=o7jlxbZe0wt81Z+7csOjUcOv21Lq1DzJVBBUvXe3gCo=; b=NIwDVI/E8+J7bPC/mHno7o0siDUzjF5BCiUumxILNmAfDMtHDbdKf2aOME8fgkyq8O yWqZ6TKAmJoaRjgzPKqKJ7Bln7tLiMMkiIzaRTTlTDJiMZIqNp0oQ38wqpK8g4rQVFko oRqLau0htz/254ZsTHbae0Nclu6rEfg1UMtQllZQ4oCZpqArcfs8qsFOZvpiXuZ8mEeN fSM83Fl7vzFmOkDreAkMYVcIxCqjsARFFPqu1mccrLI8vlPMlI20ACAXiFa/TjKirZWw l1aqW1ELvXNwvYc3sujTnkt/hWFLruRGc8FUfIEKpfj5C7Wq/rCwsx3PLdsGPdUuJPTy cGfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=o7jlxbZe0wt81Z+7csOjUcOv21Lq1DzJVBBUvXe3gCo=; b=BQqXyAFMEO0k3ZbhdM5wlrqsYU9RP6l7WgUwmzYB3DZPfRUA2v3yVIqwuQCiwUFmGW l2gBPUaaqC9pICkFwclkNZQk5uwQ+Filr5LwJ9UnS7NNhkjCXMB0ntkzPglS8qNUujbS mvykPu2fd377Ny2OWxf0b379ZfJOJ/OXZTCfL2qYn6a+VYRH/Wg/TuE/bgVXDepEXkDI uVNxGjmCV3ZqqZmELyMGSP1Nwf77UV5mWvwwOla9ObraZx1XLhQZplIaMx5C3UbjSYxu MNzQMA1zdOyYwa7v86vXsSJ57xCoxDmAJBSnfVCg4SEEuu2g6hgO/6hR9TM0/OPm6Wu9 axvw== X-Gm-Message-State: AOPr4FUENUXNdkuzWhgmy/1oZmq310ijymqHfXHYQAJ/zPGgo7LzukWns57V82i9V6pgaF1oTfTz89hiXF1UGA== MIME-Version: 1.0 X-Received: by 10.28.18.11 with SMTP id 11mr5550946wms.51.1462771967073; Sun, 08 May 2016 22:32:47 -0700 (PDT) Received: by 10.28.230.8 with HTTP; Sun, 8 May 2016 22:32:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 May 2016 23:32:47 -0600 Message-ID: From: Anthony Tavener To: Jeremy Yallop Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a114697227c261105326223ca Subject: Re: [Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes. --001a114697227c261105326223ca Content-Type: text/plain; charset=UTF-8 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. > --001a114697227c261105326223ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just tried 4.03.0 (no flambda), reco= mpiling all, and the problem still occurs. (And thanks to opam and a fast c= ompiler, this process was quick and easy!)

Jesper, those numbe= rs coming through in that problem do look similar. Anyone know what they ar= e? 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 m= arker (\1,\2) -- and it's a proper string, not like random memory.
<= br>
Gabriel, I am perfectly happy with getting bitten by "clever = code", due to a smarter compiler -- well, provided there's a way t= o express what's wanted. :)

Jeremy, I will try to reduce t= his to a simpler case with just tgls/opengl, and see if I can trap the flaw= ed cases, or make it easily reproducible. Right now I have to head out to w= ork 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 ou= t like
> "\220\552\663\1" after foreign call to OpenGL.
>
> I was seeing glitches in render output, and have tracked it down to &q= uot;uniform
> variable names" which are given as constant strings, but on OpenG= L side they
> can appear malformed.
>
> OCaml call:
>
>=C2=A0 =C2=A0 =C2=A0let color =3D Gl.get_uniform_location sp "font= Color" in
>
> In a trace of the OpenGL calls from the running program the result is<= br> > usually like this:
>
>=C2=A0 =C2=A0 =C2=A0glGetUniformLocation(program =3D 3, name =3D "= fontColor") =3D 3
>
> But on occasion (once in several hundred calls) has garbage:
>
>=C2=A0 =C2=A0 =C2=A0glGetUniformLocation(program =3D 3, name =3D "= \220\552\663\1") =3D -1
>
> The really odd thing to me is the structure of these strings (some mor= e, not
> all from "fontColor"):
>=C2=A0 =C2=A0 =C2=A0"\220=C2=A0 =C2=A0 \774\1"
>=C2=A0 =C2=A0 =C2=A0"\220\332\663\1"
>=C2=A0 =C2=A0 =C2=A0"\440\\\665\1"
>=C2=A0 =C2=A0 =C2=A0"\220\552\663\1"
>=C2=A0 =C2=A0 =C2=A0"\220J\663\1"
>=C2=A0 =C2=A0 =C2=A0"\660\117\553\2"
>=C2=A0 =C2=A0 =C2=A0"\440\220w\2"
>
> For reference, Gl.get_uniform_location is implemented thusly (in tgls)= :
>
>=C2=A0 =C2=A0let get_uniform_location =3D
>=C2=A0 =C2=A0 =C2=A0foreign ~stub "glGetUniformLocation"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(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<= br> > haven't been able to work with OCaml much in the past year), and m= y 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 t= ake a look at this.

--001a114697227c261105326223ca--