Erik de Castro Lopo | 1 Dec 01:16 2010

Re: OCamlJIT2 vs. OCamlJIT

Jon Harrop wrote:

> Because benchmarks like my HLVM ones have proven that LLVM can generate
> *much* faster code than ocamlopt does.

Until ocamlopt has an LLVM backend that is not a fair comparison.

I suspect that the speed differences between your HLVM and ocamlopt
have very little to do with LLVM and are almost totally due to 
other factors.

> LLVM is also much better documented than ocamlopt's internals.

LLVM has well over 20 full time programmers working on it. The
Ocaml compiler has how many?

Erik
--

-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Yoann Padioleau | 1 Dec 02:34 2010
Picon

Re: OCamlJIT2 vs. OCamlJIT


On Nov 30, 2010, at 4:16 PM, Erik de Castro Lopo wrote:

> 
> Jon Harrop wrote:
> 
>> Because benchmarks like my HLVM ones have proven that LLVM can generate
>> *much* faster code than ocamlopt does.
> 
> Until ocamlopt has an LLVM backend that is not a fair comparison.
> 
> I suspect that the speed differences between your HLVM and ocamlopt
> have very little to do with LLVM and are almost totally due to 
> other factors.
> 
>> LLVM is also much better documented than ocamlopt's internals.
> 
> LLVM has well over 20 full time programmers working on it. The
> Ocaml compiler has how many?

Microsoft has hundreds of developers working on C#, CIL, visual studio (and its integrated debugger), etc
and I still find ocaml and ocamldebug superior.

> 
> Erik
> -- 
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> 
(Continue reading)

Romain Beauxis | 1 Dec 02:59 2010

Re: Tips to find the cause of a seg fault

Hi,

Le mardi 30 novembre 2010 17:08:12, Philippe Veber a écrit :
> The seg fault occurs during the call to this function with the button event
> retrieved by ocamlsdl. What's really weird is that if I comment the third
> case of the pattern matching, the seg fault does not occur. This is strange
> since with the "assert false" expression, I make sure this case is useless
> (i don't press the left button). Also, in the various tests I made, I
> obtained different errors, like segmentation fault in caml_absf_mask or
> invalid instruction error.

The function that triggers the segfault may be confusing, in particular in 
case of a memory corruption, which I suspect here.
The pattern matching can cause a crash because it is using a value that is 
already corrupted and because the third case is one that, for some random 
conditions, touches the part in memory that is corrupted.

In this case, I would try to unroll the code and see where the value that is 
used in this function was instanciated.

Main source of corruption when using C bindings most often come from either 
the Gc or code executed while the global lock has been released.

In the case of a segfault hapenning during a Gc call, this can be really 
unrelated, for instance the instanciation of a new value triggers a Gc 
collection to compact memory, which in turns triggers the recollection of a 
corrupted value, which causes a segfault.

In the case of a segfault hapenning during a C call while the global lock has 
been released, you may get more useful informations through gdb, in particular 
(Continue reading)

Ilya Seleznev | 1 Dec 06:51 2010
Picon

Re: Tips to find the cause of a seg fault

On Wed, Dec 1, 2010 at 5:08 AM, Philippe Veber
<philippe.veber <at> googlemail.com> 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.

I would log mouse events, that went into 'picking_handler' to ensure
that no unexpected input sent by SDL.

--

-- 
With best regards,
Ilya Seleznev

Philippe Veber | 1 Dec 09:32 2010

Re: Tips to find the cause of a seg fault

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 <at> 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

<div>
<p>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 :<br><br>[<a href="http://main.ml">main.ml</a>]<br><span>let init () = </span><br><span>&nbsp; Sdl.init [`VIDEO ];</span><br><span>&nbsp; ignore (Sdlvideo.set_video_mode ~w:640 ~h:480 ~bpp:32 [])</span><br><br><span>open Sdlevent</span><br><span>open Sdlmouse</span><br><br><span>let picking_handler = function </span><br><span>&nbsp; | { mbe_button = BUTTON_WHEELDOWN ; mbe_state = RELEASED } -&gt; ()</span><br><span>&nbsp; | { mbe_button = BUTTON_WHEELUP ; mbe_state = RELEASED } -&gt; ()</span><br><span>&nbsp; | { mbe_button = BUTTON_LEFT ; mbe_state = RELEASED } -&gt; ()</span><br><span>&nbsp; | _ -&gt; ()</span><br><br><span>let rec handle_events () =</span><br><span>&nbsp; match wait_event () with</span><br><span>&nbsp;&nbsp;&nbsp; | QUIT -&gt; ()</span><br><span>&nbsp;&nbsp;&nbsp; | MOUSEBUTTONUP mbe -&gt;</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; picking_handler mbe ;</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; handle_events () ;</span><br><span>&nbsp;&nbsp;&nbsp; | _ -&gt; handle_events ()</span><br><br><span>let _ = init () ; handle_events () ; Sdl.quit ()</span><br><br>which can be compiled with <br><br>ocamlfind ocamlopt -o main -linkpkg -package sdl <a href="http://main.ml">main.ml</a><br><br>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 :<br><br><span>~/hum 09:22:41 $ gdb ./hum</span><br><span>GNU gdb (GDB) 7.2-ubuntu</span><br><span>Copyright (C) 2010 Free Software Foundation, Inc.</span><br><span>License GPLv3+: GNU GPL version 3 or later &lt;<a href="http://gnu.org/licenses/gpl.html">http://gnu.org/licenses/gpl.html</a>&gt;</span><br><span>This is free software: you are free to change and redistribute it.</span><br><span>There is NO WARRANTY, to the extent permitted by law.&nbsp; Type "show copying"</span><br><span>and "show warranty" for details.</span><br><span>This GDB was configured as "x86_64-linux-gnu".</span><br><span>For bug reporting instructions, please see:</span><br><span>&lt;<a href="http://www.gnu.org/software/gdb/bugs/">http://www.gnu.org/software/gdb/bugs/</a>&gt;...</span><br><span>Reading symbols from /home/pveber/hum/hum...done.</span><br><span>(gdb) run</span><br><span>Starting program: /home/pveber/hum/hum </span><br><span>[Thread debugging using libthread_db enabled]</span><br><br><span>Program received signal SIGSEGV, Segmentation fault.</span><br><span>0x000000000043ee13 in caml_absf_mask ()</span><br><span>(gdb) bt</span><br><span>#0&nbsp; 0x000000000043ee13 in caml_absf_mask ()</span><br><span>#1&nbsp; 0x000000000040d283 in camlHum__handle_events_1124 ()</span><br><span>#2&nbsp; 0x00007ffff7fce1d0 in ?? ()</span><br><span>#3&nbsp; 0x000000000040d2f1 in camlHum__entry ()</span><br><span>#4&nbsp; 0x00007ffff7f8c5a0 in ?? ()</span><br><span>#5&nbsp; 0x000000000040c2a9 in caml_program ()</span><br><span>#6&nbsp; 0x000000000008e1e4 in ?? ()</span><br><span>#7&nbsp; 0x000000000043eb56 in caml_start_program ()</span><br><span>#8&nbsp; 0x0000000000000000 in ?? ()</span><br><br>and valgrind output<br><br>~/hum 09:28:45 $ valgrind ./hum<br>==21231== Memcheck, a memory error detector<br>==21231== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.<br>==21231== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info<br>

==21231== Command: ./hum<br>==21231== <br>==21231== Invalid read of size 8<br>==21231==&nbsp;&nbsp;&nbsp; at 0x43EE13: ??? (in /home/pveber/hum/hum)<br>==21231==&nbsp;&nbsp;&nbsp; by 0x40D282: camlHum__handle_events_1124 (in /home/pveber/hum/hum)<br>
==21231==&nbsp;&nbsp;&nbsp; by 0x91921DF: ???<br>
==21231==&nbsp;&nbsp;&nbsp; by 0x40D2F0: camlHum__entry (in /home/pveber/hum/hum)<br>==21231==&nbsp;&nbsp;&nbsp; by 0x928B59F: ???<br>==21231==&nbsp;&nbsp;&nbsp; by 0x40C2A8: caml_program (in /home/pveber/hum/hum)<br>==21231==&nbsp;&nbsp;&nbsp; by 0x8E1E3: ???<br>==21231==&nbsp;&nbsp;&nbsp; by 0x43EB55: ??? (in /home/pveber/hum/hum)<br>

==21231==&nbsp; Address 0xe4 is not stack'd, malloc'd or (recently) free'd<br>==21231== <br>==21231== <br>==21231== Process terminating with default action of signal 11 (SIGSEGV)<br>==21231==&nbsp; Access not within mapped region at address 0xE4<br>

==21231==&nbsp;&nbsp;&nbsp; at 0x43EE13: ??? (in /home/pveber/hum/hum)<br>==21231==&nbsp;&nbsp;&nbsp; by 0x40D282: camlHum__handle_events_1124 (in /home/pveber/hum/hum)<br>==21231==&nbsp;&nbsp;&nbsp; by 0x91921DF: ???<br>==21231==&nbsp;&nbsp;&nbsp; by 0x40D2F0: camlHum__entry (in /home/pveber/hum/hum)<br>

==21231==&nbsp;&nbsp;&nbsp; by 0x928B59F: ???<br>==21231==&nbsp;&nbsp;&nbsp; by 0x40C2A8: caml_program (in /home/pveber/hum/hum)<br>==21231==&nbsp;&nbsp;&nbsp; by 0x8E1E3: ???<br>==21231==&nbsp;&nbsp;&nbsp; by 0x43EB55: ??? (in /home/pveber/hum/hum)<br>==21231==&nbsp; If you believe this happened as a result of a stack<br>

==21231==&nbsp; overflow in your program's main thread (unlikely but<br>==21231==&nbsp; possible), you can try to increase the size of the<br>==21231==&nbsp; main thread stack using the --main-stacksize= flag.<br>==21231==&nbsp; The main thread stack size used in this run was 8388608.<br>

==21231== <br>==21231== HEAP SUMMARY:<br>==21231==&nbsp;&nbsp;&nbsp;&nbsp; in use at exit: 2,036,382 bytes in 1,608 blocks<br>==21231==&nbsp;&nbsp; total heap usage: 13,084 allocs, 11,476 frees, 3,705,764 bytes allocated<br>==21231== <br>==21231== LEAK SUMMARY:<br>

==21231==&nbsp;&nbsp;&nbsp; definitely lost: 16 bytes in 1 blocks<br>==21231==&nbsp;&nbsp;&nbsp; indirectly lost: 176 bytes in 4 blocks<br>==21231==&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; possibly lost: 1,029,091 bytes in 15 blocks<br>==21231==&nbsp;&nbsp;&nbsp; still reachable: 1,007,099 bytes in 1,588 blocks<br>

==21231==&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; suppressed: 0 bytes in 0 blocks<br>==21231== Rerun with --leak-check=full to see details of leaked memory<br>==21231== <br>==21231== For counts of detected and suppressed errors, rerun with: -v<br>==21231== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 5 from 5)<br>

Erreur de segmentation<br><br>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.<br><br>ph.<br><br><br><br></p>
<div class="gmail_quote">

2010/12/1  <span dir="ltr">&lt;<a href="mailto:oliver <at> first.in-berlin.de">oliver <at> first.in-berlin.de</a>&gt;</span><br><blockquote class="gmail_quote">

<div class="im">On Wed, Dec 01, 2010 at 12:08:12AM +0100, Philippe Veber wrote:<br>
</div>
<div class="im">&gt; Short story (details below): I'm currently writing a program relying on<br>
&gt; react, lablgl and ocamlsdl. This program segfaults on my laptop under two<br>
&gt; linux distributions (ubuntu and gentoo) but doesn't on a PC under ubuntu.<br>
&gt; The seg fault occurs with both bytecode and native executables. I don't do<br>
</div>[...]<br><br>
A minimal program plus a Makefile would make helping easier.<br><br>
Did you tried the code with a different X-driver?<br><br>
Maybe it's a problem there.<br><br>
Or maybe something is not linked correctly against the X-libs?<br><br>
Just a guess.<br><br><br>
Ciao,<br>
 &nbsp; Oliver<br><br>
_______________________________________________<br>
Caml-list mailing list. Subscription management:<br><a href="http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list" target="_blank">http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list</a><br>
Archives: <a href="http://caml.inria.fr" target="_blank">http://caml.inria.fr</a><br>
Beginner's list: <a href="http://groups.yahoo.com/group/ocaml_beginners" target="_blank">http://groups.yahoo.com/group/ocaml_beginners</a><br>
Bug reports: <a href="http://caml.inria.fr/bin/caml-bugs" target="_blank">http://caml.inria.fr/bin/caml-bugs</a><br>
</blockquote>
</div>
<br>
</div>
oliver | 1 Dec 10:15 2010
Picon

Re: Tips to find the cause of a seg fault

Hi,

On Wed, Dec 01, 2010 at 09:32:16AM +0100, Philippe Veber wrote:
> 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 :
[...]

After installing some sdl-related packages, I could comopile the code.
So far it does not crash.

What actions do create the segfault for you?

Ciao,
   Oliver

Philippe Veber | 1 Dec 11:26 2010

Re: Tips to find the cause of a seg fault



2010/12/1 <oliver <at> first.in-berlin.de>
Hi,


On Wed, Dec 01, 2010 at 09:32:16AM +0100, Philippe Veber wrote:
> 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 :
[...]


After installing some sdl-related packages, I could comopile the code.
So far it does not crash.

What actions do create the segfault for you?

roll the mouse wheel up or down fast with the cursor on the window. However, I know that this problem does not occur everywhere, so you might well observe nothing ...

 


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

<div>
<br><br><div class="gmail_quote">2010/12/1  <span dir="ltr">&lt;<a href="mailto:oliver <at> first.in-berlin.de">oliver <at> first.in-berlin.de</a>&gt;</span><br><blockquote class="gmail_quote">

Hi,<br><div class="im">
<br><br>
On Wed, Dec 01, 2010 at 09:32:16AM +0100, Philippe Veber wrote:<br>
&gt; Actually I was not confident I could extract a small program reproducing the<br>
&gt; issue until ... you had me try ! I could get a very tiny example that<br>
&gt; behaves exactly the same, which does not involve opengl at all, only sdl.<br>
&gt; Here it is :<br>
</div>[...]<br><br><br>
After installing some sdl-related packages, I could comopile the code.<br>
So far it does not crash.<br><br>
What actions do create the segfault for you?<br>
</blockquote>
<div>
<br>roll the mouse wheel up or down fast with the cursor on the window. However, I know that this problem does not occur everywhere, so you might well observe nothing ...<br><br>&nbsp;<br>
</div>
<blockquote class="gmail_quote">
<div>
<div></div>
<div class="h5">
<br><br>
Ciao,<br>
 &nbsp; Oliver<br><br><br>
_______________________________________________<br>
Caml-list mailing list. Subscription management:<br><a href="http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list" target="_blank">http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list</a><br>
Archives: <a href="http://caml.inria.fr" target="_blank">http://caml.inria.fr</a><br>
Beginner's list: <a href="http://groups.yahoo.com/group/ocaml_beginners" target="_blank">http://groups.yahoo.com/group/ocaml_beginners</a><br>
Bug reports: <a href="http://caml.inria.fr/bin/caml-bugs" target="_blank">http://caml.inria.fr/bin/caml-bugs</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
oliver | 1 Dec 11:51 2010
Picon

Re: Tips to find the cause of a seg fault

On Wed, Dec 01, 2010 at 11:26:19AM +0100, Philippe Veber wrote:
> 2010/12/1 <oliver <at> first.in-berlin.de>
> 
> > Hi,
> >
> >
> > On Wed, Dec 01, 2010 at 09:32:16AM +0100, Philippe Veber wrote:
> > > 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 :
> > [...]
> >
> >
> > After installing some sdl-related packages, I could comopile the code.
> > So far it does not crash.
> >
> > What actions do create the segfault for you?
> >
> 
> roll the mouse wheel up or down fast with the cursor on the window. However,
> I know that this problem does not occur everywhere, so you might well
> observe nothing ...
[...]

No crash happened.

Normally I'm very gifted to crash software.... by just looking at it.

If there is a bug, it will find me  ;)

Did you tried another X-driver?

In your valgrind printout there was mentioned "libnvidia".
And a crash seems to have been occured at that part:

> ==11306==    by 0x4215D5: camlHum__entry (in
> /home/pveber/hum/_build/src/hum.native)
> ==11306==    by 0xC5767A7: ???
> ==11306==
> ==11306== Conditional jump or move depends on uninitialised value(s)
> ==11306==    at 0x7695580: ??? (in
> /usr/lib/nvidia-current/libnvidia-glcore.so.260.19.06)
> ==11306==    by 0x1000000000000: ???
> ==11306==
> vex amd64->IR: unhandled instruction bytes: 0xFF 0xD8 0xC 0xF9 0xFF 0xD8
> ==11306== valgrind: Unrecognised instruction at address 0x4992cb.
> ==11306== Your program just tried to execute an instruction that Valgrind

So, please chack this. Maybe one of the free drivers does work better,
or maybe an update could help.

If you update your kernel, then you might also need to update the
X-drivers, because the nvidia stuff is non-free binary stuff,
and maybe some bindings don't work correctly with a new kernel.

I once experienced problems the other way around: crashing blender
with the free drivers, just by scaling into a view more and more,
and no crash with the non-free drivers.

This X11-driver part is really a desert...

...and even if you don't use OpenGL commands... the driver that you installed
and configured will be used nevretheless, and if there is something wrong, you
will get your crashes.

Look if the X11-driver-bindings are all up to date for the driver you use now,
and also try another X11-driver...

Ciao,
   Oliver

Alain Frisch | 1 Dec 12:43 2010

Re: Desktop GUI toolkits - current state of the art?

On 11/24/2010 10:47 AM, Martin DeMello wrote:
> On Wed, Nov 24, 2010 at 5:02 AM, Alain Frisch<alain.frisch <at> lexifi.com>  wrote:
>> We have a few local extensions to the OCaml compiler that makes it easier to
>> build nice APIs for GUI toolkits, with a functional flavor: implicit
>> subtyping and generalized recursion. Hopefully, I'll be able to blog about
>> these extensions and how they are used for GUI programming some day.
>
> I'd love to read that when you do. I was surprised not to see much
> interest in GUI DSLs in OCaml. What is generalised recursion?

FWIW, I've blogged about our extensions related to laziness:

https://www.lexifi.com/blog/ocaml-extensions-lexifi-semi-implicit-laziness

-- Alain

Jon Harrop | 1 Dec 13:58 2010

RE: OCamlJIT2 vs. OCamlJIT

Erik wrote:
> Jon wrote:
> > LLVM is also much better documented than ocamlopt's internals.
> 
> LLVM has well over 20 full time programmers working on it. The
> Ocaml compiler has how many?

Another reason why LLVM deserves its hype.

Cheers,
Jon.


Gmane