Re: [Caml-list] Tips to find the cause of a seg fault

[Philippe Veber <philippe.veber@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 5788 bytes --]

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 <http://gnu.org/licenses/gpl.html
>
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:
<http://www.gnu.org/software/gdb/bugs/>...
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 <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'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
>

[-- Attachment #2: Type: text/html, Size: 11906 bytes --]