From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id E46E77EE88 for ; Sun, 8 May 2016 19:08:14 +0200 (CEST) IronPort-PHdr: 9a23:Uvu6qR/EKImqmP9uRHKM819IXTAuvvDOBiVQ1KB91OocTK2v8tzYMVDF4r011RmSDdSdsqoP0rKG+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuSt+U1pz8jrjis7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cY6Lod8JsKWqz/e+E8TKdEJDUgKWE8osPx/1GXRgKK4j4YU34KuhtOGQnMqh/gCMTfqCz/48N7xCmdO9y+cbkqVDKv9e8/QRn0iCABJngl+X/ajMFqpK1eqROl4Rd4xtiHM8muKPNic/aFLpshTm1bU5MJWg== Authentication-Results: mail2-smtp-roc.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-f50.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=74.125.82.50; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of anthony.tavener@gmail.com designates 74.125.82.50 as permitted sender) identity=mailfrom; client-ip=74.125.82.50; receiver=mail2-smtp-roc.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 (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wm0-f50.google.com) identity=helo; client-ip=74.125.82.50; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-wm0-f50.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARAQAPci9XjzJSfUpeg1aBNAamPwQDhzSGFIZ4hycHPBABAQEBAQEBAREBAQEBBwsLCSEkC4Itgi0RBBkBGx4DEgMGBzcCJAERAQUBIjWHcgEDE5BXjTuCB4ExPjGLO4FqgliGNwoZJw1ShA8BBQoFhhGMC4JZBY1edIlQgS4njEePF419Eh6BDjeCQYF0HTKJBgEBAQ X-IPAS-Result: A0ARAQAPci9XjzJSfUpeg1aBNAamPwQDhzSGFIZ4hycHPBABAQEBAQEBAREBAQEBBwsLCSEkC4Itgi0RBBkBGx4DEgMGBzcCJAERAQUBIjWHcgEDE5BXjTuCB4ExPjGLO4FqgliGNwoZJw1ShA8BBQoFhhGMC4JZBY1edIlQgS4njEePF419Eh6BDjeCQYF0HTKJBgEBAQ X-IronPort-AV: E=Sophos;i="5.24,596,1454972400"; d="scan'208,217";a="217301799" Received: from mail-wm0-f50.google.com ([74.125.82.50]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 08 May 2016 19:08:08 +0200 Received: by mail-wm0-f50.google.com with SMTP id g17so150735455wme.1 for ; Sun, 08 May 2016 10:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=8ROmkUl/0Jxeu/OzaQjH0/nON5gOYpkoEDmVPv5YM28=; b=I2Rd8RuFxmQuI4QZBmWwAtOJoT3M67v1wd+HoW01YRryAJ1dGdmOxnDlX4421XX7e7 D6WX48ezG52fUNq1GsS0KZ4KC9HraqfoT2eVryZ/6XBRWpgJ8j4I1nR4oF/l/2//Wzuh 0GjM9Yk8pAuh+EpuPOlVf6qLtH9If0/pF6+EIRPOz9dg45UmdPb63Ywltq4Ro28ktz3Z wsssDphBXJNUBgQR6CLBIfBIdiycR4JMVweGUrsmIoS2Pax+QneXXJKoOxwl6R9VnsW5 wEvWubIBPGj+z3TbuxRLzJN6WpbNTo5QQeEcvmRYW134q0uHFWb/VDuEv1/Uqv/7RQM2 jXvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=8ROmkUl/0Jxeu/OzaQjH0/nON5gOYpkoEDmVPv5YM28=; b=BOPNhn4GOVPs+2IXf1ujHkTBAcsgdAj2naAYBMwtR6jSL2VvvcRRyHYumF6+kCowK4 U8FBO+MlJqdcCyw04snv+jXUWwVIMBLa+KExYslfbs4KprBMT2pMMuMTRL4C+8eyBUUA 0qqpMD0TYRJjFMdhnf3SqE7Rf1jycslntS/lPjugz6VWV6eF87KRjzoGIlpmzAgPfciv RCvaectsNTxdzn4P4s8LLsSW96YdMQeNPCwADYWJbzRcZ0MeUvJL62BirGLm2/54Bz/w 1EsGbyJhN17Rq2meo5WdzOrXWAGDzclBrit7+SlQBGVx+DZwTsFDU9P1SjlJGgo30nMt fk6g== X-Gm-Message-State: AOPr4FWAPZmby4JyM/4gVKUhXf5LG5DgwbhthL4V/b6VazGNDaaY0Jc76GnS4FDNCNgM5V5e4IE84IjJypmavw== MIME-Version: 1.0 X-Received: by 10.28.18.11 with SMTP id 11mr3746266wms.51.1462727288388; Sun, 08 May 2016 10:08:08 -0700 (PDT) Received: by 10.28.230.8 with HTTP; Sun, 8 May 2016 10:08:08 -0700 (PDT) Date: Sun, 8 May 2016 11:08:08 -0600 Message-ID: From: Anthony Tavener To: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a114697226d87ef053257bcd8 Subject: [Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes. --001a114697226d87ef053257bcd8 Content-Type: text/plain; charset=UTF-8 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 --001a114697226d87ef053257bcd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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, an= d have tracked it down to "uniform variable names" which are give= n as constant strings, but on OpenGL side they can appear malformed.
OCaml call:

=C2=A0=C2=A0=C2=A0 let color =3D Gl.get_uniform_l= ocation sp "fontColor" in

In a trace of the OpenGL c= alls from the running program the result is usually like this:

= =C2=A0=C2=A0=C2=A0 glGetUniformLocation(program =3D 3, name =3D "fontC= olor") =3D 3

But on occasion (once in sever= al hundred calls) has garbage:

=C2=A0 =C2=A0 glGetUniform= Location(program =3D 3, name =3D "\220\552\663\1") =3D -1

=
The really odd thing to me is the structure of these strings (so= me more, not all from "fontColor"):
=C2=A0 =C2=A0 "\220= =C2=A0=C2=A0=C2=A0 \774\1"
=C2=A0=C2=A0=C2=A0 "\220\332\663\1&= quot;
=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 i= mplemented thusly (in tgls):

=C2=A0 let get_uniform_location =3D
= =C2=A0=C2=A0=C2=A0 foreign ~stub "glGetUniformLocation"
=C2=A0= =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 versio= ns (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 c= ase 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!

=C2=A0-Tony

--001a114697226d87ef053257bcd8--