From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <philippe.veber@googlemail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by yquem.inria.fr (Postfix) with ESMTP id E9276BBAF
	for <caml-list@yquem.inria.fr>; Sun,  5 Dec 2010 15:50:57 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtcAAKI1+0zRVda2kGdsb2JhbACUaoYuAYgQCBUBAQEBCQkMBxEEHqNrjAIBBY0JAQSFSYFgiRI
X-IronPort-AV: E=Sophos;i="4.59,302,1288566000"; 
   d="scan'208";a="83130409"
Received: from mail-iw0-f182.google.com ([209.85.214.182])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 05 Dec 2010 15:50:57 +0100
Received: by iwn39 with SMTP id 39so13998921iwn.27
        for <multiple recipients>; Sun, 05 Dec 2010 06:50:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=gamma;
        h=domainkey-signature:received:mime-version:received:in-reply-to
         :references:from:date:message-id:subject:to:cc:content-type;
        bh=vPrl4MFzPBaA+yNDyVeD5jOgtiIpHTLtwftduqRJOWg=;
        b=ILAJAEG3HlQ5tT/bB2F2k+/55MWIaCZHBW3zyBIfqGHNuW9Mq27xxwqKNrf+3udb34
         wbrIpeTCN67AzEOQbjQ7Ws7bSYl5JVLFQa8svNJ6atua39Cqbq8lfxgHKn8Qnu9JscPu
         tCqhi1gkhIhk8cYIqOiOfDWjhHgUBZHGWUOho=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=pfj6nuXgH3sluaaHRMx2bmpCdbL42zh/tFsqKR9GQx/cKyqfk8XhMXeKIY03jkAJaH
         rWWC/Ef63hIdw76C8Rm252P89DcsRidvyM/I4CeJf0p0+U2bWLbagbvEMRokVk//SwKZ
         u5F6iS4GPKF/LbTjC+FRtlCyEpTPmTG+p/JsE=
Received: by 10.231.17.11 with SMTP id q11mr4508767iba.102.1291560654993; Sun,
 05 Dec 2010 06:50:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.176.134 with HTTP; Sun, 5 Dec 2010 06:50:34 -0800 (PST)
In-Reply-To: <3474B264-1D16-4740-B935-995B6B38F0CE@inria.fr>
References: <1182061596.483210.1291158525016.JavaMail.root@zmbs1.inria.fr> <3474B264-1D16-4740-B935-995B6B38F0CE@inria.fr>
From: Philippe Veber <philippe.veber@googlemail.com>
Date: Sun, 5 Dec 2010 15:50:34 +0100
Message-ID: <AANLkTimUSh8YMyxcJM3XpKDfF3f78dhaUGd14ofmA=De@mail.gmail.com>
Subject: Re: [Caml-list] Tips to find the cause of a seg fault
To: Damien Doligez <damien.doligez@inria.fr>
Cc: caml users <caml-list@inria.fr>
Content-Type: multipart/alternative; boundary=00032557497e0c07cc0496aae625
X-Spam: no; 0.00; segfault:01 corresponded:01 ocamlsdl:01 variants:01 ocamlsdl:01 cheers:01 damien:01 damien:01 lablgl:01 segfaults:01 gentoo:01 bytecode:01 marshaling:01 gdb:01 ocaml:01 

--00032557497e0c07cc0496aae625
Content-Type: text/plain; charset=ISO-8859-1

Thanks everyone for your answers. For the record, I finally understood the
cause of my problem: first I noticed that I had no segfault on the same
machine replacing my touchpad with a usual mouse. I then wrote a C
equivalent of my minimal program, which worked perfectly (also according to
valgrind). This basically meant the problem lied in the binding. So I
finally checked at the C level every mouse event incoming and saw that there
were mouse button events containing unexpected mouse button codes. These
codes corresponded to horizontal two finger scrolling, that is indeed not
available on a standard mouse, and not incorporated in ocamlsdl API. The
thing is that button codes are used directly to encode variants in the
binding and, as a consequence used to compute a jump in the pattern
matching. So what happened is the following: by using vertical two finger
scrolling a bit too fast, I would also generate (unintentionally) an
horizontal scrolling event at the end of my move, and right after that do a
pattern matching on its variant representation, which triggered a jump in
some unexpected zone of memory, leading to either segmentation fault or
illegal instruction error.

So, long story short: doing pattern matching on mouse events of ocamlsdl (or
the sdl binding of glcaml, by the way) may lead to a crash when using a
touchpad. For now I'll use a cheap workaround in my program, but if the
authors of ocamlsdl are interested, I'll gladly work on a patch.

cheers,
ph.


2010/12/3 Damien Doligez <damien.doligez@inria.fr>

>
> On 2010-12-01, at 00:08, Philippe Veber wrote:
>
> > Short story (details below): I'm currently writing a program relying on
> react, lablgl and ocamlsdl. This program segfaults on my laptop under two
> linux distributions (ubuntu and gentoo) but doesn't on a PC under ubuntu.
> The seg fault occurs with both bytecode and native executables. I don't do
> any marshaling nor use any typing magic; stack overflow is not likely. I
> humbly ask this list about means to improve valgrind or gdb outputs, which
> don't report informative function names, or more generally, any tip that
> could help me to locate the origin of the problem.
>
> You should try to compile the OCaml runtime in debug mode: just "make
> ocamlrund"
> in the ...ocaml/bytecode directory, then run your program with ocamlrund.
>
> > Many thanks for the clarification. Maybe I could (partially) "unplug" the
> GC by setting space_overhead to 100 ? That could give an indication on the
> moment the problem occurs ?
>
> The default space_overhead is already 80.  If you want the major GC
> to run very slowly, set the overhead to 1000 or 10000.  But usually
> you want to do the opposite, so that the crash happens soon after the
> execution of the buggy code.  You can try to pepper your code with
> calls to Gc.compact, for example.  In your case, I would call it just
> before the pattern matching that crashes mysteriously.
>
> -- Damien
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

--00032557497e0c07cc0496aae625
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks everyone for your answers. For the record, I finally understood the =
cause of my problem: first I noticed that I had no segfault on the same mac=
hine replacing my touchpad with a usual mouse. I then wrote a C equivalent =
of my minimal program, which worked perfectly (also according to valgrind).=
 This basically meant the problem lied in the binding. So I finally checked=
 at the C level every mouse event incoming and saw that there were mouse bu=
tton events containing unexpected mouse button codes. These codes correspon=
ded to horizontal two finger scrolling, that is indeed not available on a s=
tandard mouse, and not incorporated in ocamlsdl API. The thing is that butt=
on codes are used directly to encode variants in the binding and, as a cons=
equence used to compute a jump in the pattern matching. So what happened is=
 the following: by using vertical two finger scrolling a bit too fast, I wo=
uld also generate (unintentionally) an horizontal scrolling event at the en=
d of my move, and right after that do a pattern matching on its variant rep=
resentation, which triggered a jump in some unexpected zone of memory, lead=
ing to either segmentation fault or illegal instruction error.<br>

<br>So, long story short: doing pattern matching on mouse events of ocamlsd=
l (or the sdl binding of glcaml, by the way) may lead to a crash when using=
 a touchpad. For now I&#39;ll use a cheap workaround in my program, but if =
the authors of ocamlsdl are interested, I&#39;ll gladly work on a patch.<br=
>

<br>cheers,<br>ph.<br><br><br><div class=3D"gmail_quote">2010/12/3 Damien D=
oligez <span dir=3D"ltr">&lt;<a href=3D"mailto:damien.doligez@inria.fr">dam=
ien.doligez@inria.fr</a>&gt;</span><br><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204)=
; padding-left: 1ex;">

<div class=3D"im"><br>
On 2010-12-01, at 00:08, Philippe Veber wrote:<br>
<br>
&gt; Short story (details below): I&#39;m currently writing a program relyi=
ng on react, lablgl and ocamlsdl. This program segfaults on my laptop under=
 two linux distributions (ubuntu and gentoo) but doesn&#39;t on a PC under =
ubuntu. The seg fault occurs with both bytecode and native executables. I d=
on&#39;t do any marshaling nor use any typing magic; stack overflow is not =
likely. I humbly ask this list about means to improve valgrind or gdb outpu=
ts, which don&#39;t report informative function names, or more generally, a=
ny tip that could help me to locate the origin of the problem.<br>


<br>
</div>You should try to compile the OCaml runtime in debug mode: just &quot=
;make ocamlrund&quot;<br>
in the ...ocaml/bytecode directory, then run your program with ocamlrund.<b=
r>
<div class=3D"im"><br>
&gt; Many thanks for the clarification. Maybe I could (partially) &quot;unp=
lug&quot; the GC by setting space_overhead to 100 ? That could give an indi=
cation on the moment the problem occurs ?<br>
<br>
</div>The default space_overhead is already 80. =A0If you want the major GC=
<br>
to run very slowly, set the overhead to 1000 or 10000. =A0But usually<br>
you want to do the opposite, so that the crash happens soon after the<br>
execution of the buggy code. =A0You can try to pepper your code with<br>
calls to Gc.compact, for example. =A0In your case, I would call it just<br>
before the pattern matching that crashes mysteriously.<br>
<font color=3D"#888888"><br>
-- Damien<br>
</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
Caml-list mailing list. Subscription management:<br>
<a href=3D"http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list" target=
=3D"_blank">http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list</a><br=
>
Archives: <a href=3D"http://caml.inria.fr" target=3D"_blank">http://caml.in=
ria.fr</a><br>
Beginner&#39;s list: <a href=3D"http://groups.yahoo.com/group/ocaml_beginne=
rs" target=3D"_blank">http://groups.yahoo.com/group/ocaml_beginners</a><br>
Bug reports: <a href=3D"http://caml.inria.fr/bin/caml-bugs" target=3D"_blan=
k">http://caml.inria.fr/bin/caml-bugs</a><br>
</div></div></blockquote></div><br>

--00032557497e0c07cc0496aae625--