From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 C7AD7BC57 for ; Wed, 1 Dec 2010 09:32:38 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgAADSW9UzRVda2imdsb2JhbACUUoYrAYgLCBUBAQEKCQwHDwYeqWOLfAEFjgQBBIVHgWCJBw X-IronPort-AV: E=Sophos;i="4.59,282,1288566000"; d="scan'208";a="82044053" Received: from mail-iw0-f182.google.com ([209.85.214.182]) by mail2-smtp-roc.national.inria.fr with ESMTP; 01 Dec 2010 09:32:37 +0100 Received: by iwn39 with SMTP id 39so8556140iwn.27 for ; Wed, 01 Dec 2010 00:32:37 -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=vA0iUhZAAIO0o2EG0w4c62SjjsFgt74h3qwy0O7MQ1U=; b=TXzJpx6N6OtEeicPRtw483ISfUeJpMYElRqwLHHYPEJzUHprZsTQJtFdww2MqRvPmA UrMek9pIonGKqp81cLbxApB6vz7emOcZ6QoEe1qLcRrMYfCp4oC/EBlAU5AuDsZ/d9SN uIBL6bMmWAcdGXIbFsWxZSr7N8dhI4lXD+E3k= 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=cbQgCO8HB8/J3hCuD4bI/CsyzMYLM/Kq+fM73VfLkQ33yCfiXuh+ExGPkCyrfynqZQ Up53Eq4NWUXpih3qWNKqeQTHv243ujl1Vd0pdysKwlG6F1GrMJD3TI7JyceGMzClvDT1 0qzq6WlxUJhlE24pMaa7tkbq1ovmZaM80+8+k= Received: by 10.231.32.66 with SMTP id b2mr8626092ibd.27.1291192357113; Wed, 01 Dec 2010 00:32:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.176.134 with HTTP; Wed, 1 Dec 2010 00:32:16 -0800 (PST) In-Reply-To: <20101130231804.GB21723@siouxsie> References: <20101130231804.GB21723@siouxsie> From: Philippe Veber Date: Wed, 1 Dec 2010 09:32:16 +0100 Message-ID: Subject: Re: [Caml-list] Tips to find the cause of a seg fault To: oliver@first.in-berlin.de Cc: caml users Content-Type: multipart/alternative; boundary=002215048b67c85857049655255d X-Spam: no; 0.00; sdlvideo:01 bpp:01 ocamlfind:01 ocamlopt:01 -linkpkg:01 -package:01 backtrace:01 gdb:01 gdb:01 redistribute:01 bug:01 terminating:01 in-berlin:01 0100,:01 lablgl:01 --002215048b67c85857049655255d Content-Type: text/plain; charset=ISO-8859-1 Actually I was not confident I could extract a small program reproducing the issue until ... you had me try ! I could get a very tiny example that behaves exactly the same, which does not involve opengl at all, only sdl. Here it is : [main.ml] let init () = Sdl.init [`VIDEO ]; ignore (Sdlvideo.set_video_mode ~w:640 ~h:480 ~bpp:32 []) open Sdlevent open Sdlmouse let picking_handler = function | { mbe_button = BUTTON_WHEELDOWN ; mbe_state = RELEASED } -> () | { mbe_button = BUTTON_WHEELUP ; mbe_state = RELEASED } -> () | { mbe_button = BUTTON_LEFT ; mbe_state = RELEASED } -> () | _ -> () let rec handle_events () = match wait_event () with | QUIT -> () | MOUSEBUTTONUP mbe -> picking_handler mbe ; handle_events () ; | _ -> handle_events () let _ = init () ; handle_events () ; Sdl.quit () which can be compiled with ocamlfind ocamlopt -o main -linkpkg -package sdl main.ml On my laptop, this one seg faults unless i remove the third case of the pattern (but that may not be very meaningful, as Romain explained). I can report the backtrace offered by gdb : ~/hum 09:22:41 $ gdb ./hum GNU gdb (GDB) 7.2-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /home/pveber/hum/hum...done. (gdb) run Starting program: /home/pveber/hum/hum [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x000000000043ee13 in caml_absf_mask () (gdb) bt #0 0x000000000043ee13 in caml_absf_mask () #1 0x000000000040d283 in camlHum__handle_events_1124 () #2 0x00007ffff7fce1d0 in ?? () #3 0x000000000040d2f1 in camlHum__entry () #4 0x00007ffff7f8c5a0 in ?? () #5 0x000000000040c2a9 in caml_program () #6 0x000000000008e1e4 in ?? () #7 0x000000000043eb56 in caml_start_program () #8 0x0000000000000000 in ?? () and valgrind output ~/hum 09:28:45 $ valgrind ./hum ==21231== Memcheck, a memory error detector ==21231== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==21231== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==21231== Command: ./hum ==21231== ==21231== Invalid read of size 8 ==21231== at 0x43EE13: ??? (in /home/pveber/hum/hum) ==21231== by 0x40D282: camlHum__handle_events_1124 (in /home/pveber/hum/hum) ==21231== by 0x91921DF: ??? ==21231== by 0x40D2F0: camlHum__entry (in /home/pveber/hum/hum) ==21231== by 0x928B59F: ??? ==21231== by 0x40C2A8: caml_program (in /home/pveber/hum/hum) ==21231== by 0x8E1E3: ??? ==21231== by 0x43EB55: ??? (in /home/pveber/hum/hum) ==21231== Address 0xe4 is not stack'd, malloc'd or (recently) free'd ==21231== ==21231== ==21231== Process terminating with default action of signal 11 (SIGSEGV) ==21231== Access not within mapped region at address 0xE4 ==21231== at 0x43EE13: ??? (in /home/pveber/hum/hum) ==21231== by 0x40D282: camlHum__handle_events_1124 (in /home/pveber/hum/hum) ==21231== by 0x91921DF: ??? ==21231== by 0x40D2F0: camlHum__entry (in /home/pveber/hum/hum) ==21231== by 0x928B59F: ??? ==21231== by 0x40C2A8: caml_program (in /home/pveber/hum/hum) ==21231== by 0x8E1E3: ??? ==21231== by 0x43EB55: ??? (in /home/pveber/hum/hum) ==21231== If you believe this happened as a result of a stack ==21231== overflow in your program's main thread (unlikely but ==21231== possible), you can try to increase the size of the ==21231== main thread stack using the --main-stacksize= flag. ==21231== The main thread stack size used in this run was 8388608. ==21231== ==21231== HEAP SUMMARY: ==21231== in use at exit: 2,036,382 bytes in 1,608 blocks ==21231== total heap usage: 13,084 allocs, 11,476 frees, 3,705,764 bytes allocated ==21231== ==21231== LEAK SUMMARY: ==21231== definitely lost: 16 bytes in 1 blocks ==21231== indirectly lost: 176 bytes in 4 blocks ==21231== possibly lost: 1,029,091 bytes in 15 blocks ==21231== still reachable: 1,007,099 bytes in 1,588 blocks ==21231== suppressed: 0 bytes in 0 blocks ==21231== Rerun with --leak-check=full to see details of leaked memory ==21231== ==21231== For counts of detected and suppressed errors, rerun with: -v ==21231== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 5 from 5) Erreur de segmentation I'm sorry I started with a long explanation instead of this. Thanks to your advice, I have far better chances to find what's going on. ph. 2010/12/1 > On Wed, Dec 01, 2010 at 12:08:12AM +0100, 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 > [...] > > A minimal program plus a Makefile would make helping easier. > > Did you tried the code with a different X-driver? > > Maybe it's a problem there. > > Or maybe something is not linked correctly against the X-libs? > > Just a guess. > > > Ciao, > Oliver > > _______________________________________________ > 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 > --002215048b67c85857049655255d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually I was not confident I could extract a small program reproducing th= e issue until ... you had me try ! I could get a very tiny example that beh= aves exactly the same, which does not involve opengl at all, only sdl. Here= it is :

[main.ml]
let init () =3D
= =A0 Sdl.init [`VIDEO ];
=A0 ignore (Sdlvideo.se= t_video_mode ~w:640 ~h:480 ~bpp:32 [])

open Sdlevent
open Sdlmouse
l= et picking_handler =3D function
=A0 | { mbe_button =3D = BUTTON_WHEELDOWN ; mbe_state =3D RELEASED } -> ()
=A0 | { mbe_button =3D BUTTON_WHEELUP ; mbe_state =3D RELEASED }= -> ()
=A0 | { mbe_button =3D = BUTTON_LEFT ; mbe_state =3D RELEASED } -> ()
=A0 | _ -> ()

let rec handle_events () =3D
=A0 match wait_event () with
=A0=A0=A0 | QUIT -> = ()
=A0=A0=A0 | MOUSEBUTTONUP mbe ->
=A0=A0=A0=A0=A0 picking= _handler mbe ;
=A0=A0=A0=A0=A0 handle_even= ts () ;
=A0=A0=A0 | _ -> han= dle_events ()

let _ =3D init () ; handle_events () ; Sdl.quit ()

which can be compiled with

ocamlfind ocamlopt -o main -linkpkg = -package sdl main.ml

On my laptop, th= is one seg faults unless i remove the third case of the pattern (but that m= ay not be very meaningful, as Romain explained). I can report the backtrace= offered by gdb :

~/hum 09:22:41 $ gd= b ./hum
GNU gdb (GDB) 7.2-ubuntu Copyright (C) 2010 Free= Software Foundation, Inc.
License GPLv3+:= GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: = you are free to change and redistribute it.
and "show warranty= " for details.
This GDB was configure= d as "x86_64-linux-gnu".
For bug reporting instr= uctions, please see:
<http://www.gnu.org/software/gdb/bugs/&= gt;...
Reading symbols from /h= ome/pveber/hum/hum...done.
(gdb) run
Starting program: /home= /pveber/hum/hum
[Thread debugging using l= ibthread_db enabled]
Program received signal SIGSEGV, Segmentation fa= ult.
0x000000000043ee13 in caml_absf_mask = ()
(gdb) bt
#0=A0 0x000000000043ee13 in caml_absf_mask ()
#1=A0 0x000000000040d28= 3 in camlHum__handle_events_1124 ()
#2=A0 = 0x00007ffff7fce1d0 in ?? ()
#3=A0 0x000000000040d2f= 1 in camlHum__entry ()
#4=A0 0x00007ffff7f= 8c5a0 in ?? ()
#5=A0 0x000000000040c2a= 9 in caml_program ()
#6=A0 0x000000000008e= 1e4 in ?? ()
#7=A0 0x000000000043eb5= 6 in caml_start_program ()
#8=A0 0x0000000= 000000000 in ?? ()

and valgrind output

~/hum 09:28:45 $ valgrind ./hum
=3D=3D212= 31=3D=3D Memcheck, a memory error detector
=3D=3D21231=3D=3D Copyright (= C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
=3D=3D21231=3D= =3D Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright= info
=3D=3D21231=3D=3D Command: ./hum
=3D=3D21231=3D=3D
=3D=3D21231=3D=3D= Invalid read of size 8
=3D=3D21231=3D=3D=A0=A0=A0 at 0x43EE13: ??? (in = /home/pveber/hum/hum)
=3D=3D21231=3D=3D=A0=A0=A0 by 0x40D282: camlHum__h= andle_events_1124 (in /home/pveber/hum/hum)
=3D=3D21231=3D=3D=A0=A0=A0 by 0x91921DF: ???
=3D=3D21231=3D=3D=A0=A0=A0 by 0x40D2F0: camlHum__entry (in /home/pveber/hum= /hum)
=3D=3D21231=3D=3D=A0=A0=A0 by 0x928B59F: ???
=3D=3D21231=3D=3D= =A0=A0=A0 by 0x40C2A8: caml_program (in /home/pveber/hum/hum)
=3D=3D2123= 1=3D=3D=A0=A0=A0 by 0x8E1E3: ???
=3D=3D21231=3D=3D=A0=A0=A0 by 0x43EB55:= ??? (in /home/pveber/hum/hum)
=3D=3D21231=3D=3D=A0 Address 0xe4 is not stack'd, malloc'd or (rece= ntly) free'd
=3D=3D21231=3D=3D
=3D=3D21231=3D=3D
=3D=3D21231= =3D=3D Process terminating with default action of signal 11 (SIGSEGV)
= =3D=3D21231=3D=3D=A0 Access not within mapped region at address 0xE4
=3D=3D21231=3D=3D=A0=A0=A0 at 0x43EE13: ??? (in /home/pveber/hum/hum)
= =3D=3D21231=3D=3D=A0=A0=A0 by 0x40D282: camlHum__handle_events_1124 (in /ho= me/pveber/hum/hum)
=3D=3D21231=3D=3D=A0=A0=A0 by 0x91921DF: ???
=3D= =3D21231=3D=3D=A0=A0=A0 by 0x40D2F0: camlHum__entry (in /home/pveber/hum/hu= m)
=3D=3D21231=3D=3D=A0=A0=A0 by 0x928B59F: ???
=3D=3D21231=3D=3D=A0=A0=A0 = by 0x40C2A8: caml_program (in /home/pveber/hum/hum)
=3D=3D21231=3D=3D=A0= =A0=A0 by 0x8E1E3: ???
=3D=3D21231=3D=3D=A0=A0=A0 by 0x43EB55: ??? (in /= home/pveber/hum/hum)
=3D=3D21231=3D=3D=A0 If you believe this happened a= s a result of a stack
=3D=3D21231=3D=3D=A0 overflow in your program's main thread (unlikely b= ut
=3D=3D21231=3D=3D=A0 possible), you can try to increase the size of t= he
=3D=3D21231=3D=3D=A0 main thread stack using the --main-stacksize=3D = flag.
=3D=3D21231=3D=3D=A0 The main thread stack size used in this run w= as 8388608.
=3D=3D21231=3D=3D
=3D=3D21231=3D=3D HEAP SUMMARY:
=3D=3D21231=3D=3D= =A0=A0=A0=A0 in use at exit: 2,036,382 bytes in 1,608 blocks
=3D=3D21231= =3D=3D=A0=A0 total heap usage: 13,084 allocs, 11,476 frees, 3,705,764 bytes= allocated
=3D=3D21231=3D=3D
=3D=3D21231=3D=3D LEAK SUMMARY:
=3D=3D21231=3D=3D=A0=A0=A0 definitely lost: 16 bytes in 1 blocks
=3D=3D2= 1231=3D=3D=A0=A0=A0 indirectly lost: 176 bytes in 4 blocks
=3D=3D21231= =3D=3D=A0=A0=A0=A0=A0 possibly lost: 1,029,091 bytes in 15 blocks
=3D=3D= 21231=3D=3D=A0=A0=A0 still reachable: 1,007,099 bytes in 1,588 blocks
=3D=3D21231=3D=3D=A0=A0=A0=A0=A0=A0=A0=A0 suppressed: 0 bytes in 0 blocks=3D=3D21231=3D=3D Rerun with --leak-check=3Dfull to see details of leaked= memory
=3D=3D21231=3D=3D
=3D=3D21231=3D=3D For counts of detected a= nd suppressed errors, rerun with: -v
=3D=3D21231=3D=3D ERROR SUMMARY: 2 = errors from 1 contexts (suppressed: 5 from 5)
Erreur de segmentation

I'm sorry I started with a long explanati= on instead of this. Thanks to your advice, I have far better chances to fin= d what's going on.

ph.



2010/12/1 <oliver@first.in-berlin.de>
On Wed, Dec 01, 2010 at 12:08:12AM +0100, 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&= #39;t do
[...]

A minimal program plus a Makefile would make helping easier.

Did you tried the code with a different X-driver?

Maybe it's a problem there.

Or maybe something is not linked correctly against the X-libs?

Just a guess.


Ciao,
=A0 Oliver

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.in= ria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--002215048b67c85857049655255d--