Floating exception

Floating exception

[Sebastien Ferre]

Hi,

I compiled an OCaml program in native code on
my new Linux machine. It runs without problem on
this machine, but crashes as soon as it is executed
with "Floating exception" on another Linux machine.
The 2 machines have a similar processors (Intel Core Duo
and Intel Xeon).

What puzzles me is that it was working properly
with my previous machine, which was very similar
to the new one (Dell D400 -> D420).
Another change is that I shifted from OCaml 3.08
to OCaml 3.09.

Does anybody have an idea of the cause of such an
obscure error ? and how to solve it ? :-)

Sebastien

Re: [Caml-list] Floating exception

[Jon Harrop]

On Friday 23 November 2007 18:08, Sebastien Ferre wrote:
> I compiled an OCaml program in native code on
> my new Linux machine. It runs without problem on
> this machine, but crashes as soon as it is executed
> with "Floating exception" on another Linux machine.
> The 2 machines have a similar processors (Intel Core Duo
> and Intel Xeon).
>
> What puzzles me is that it was working properly
> with my previous machine, which was very similar
> to the new one (Dell D400 -> D420).
> Another change is that I shifted from OCaml 3.08
> to OCaml 3.09.
>
> Does anybody have an idea of the cause of such an
> obscure error ? and how to solve it ? :-)

We shipped our first and last binary commercial product written in OCaml about 
two and a half years ago: presentation software for technical users 
called "Presenta" that provided integrated real-time 2D and 3D graphics 
rendered via OpenGL.

Too many of our users found the binary generated by ocamlopt to be unusably 
unreliable, typically due to random segfaulting that we could not reproduce. 
Consequently, we were forced to shelve the product line and never bothered 
trying to sell binaries generated by ocamlopt again. We've since stripped out 
the core renderer (Smoke) and are now giving it away for free in bytecode 
form and selling the source code:

  http://www.ffconsultancy.com/products/smoke_vector_graphics/

I was interested to hear about John Whitington's commercial product cPDF:

  http://www.coherentgraphics.co.uk/cpdf.html

I believe our problems were with library interop (e.g. using OpenGL from 
OCaml). cPDF works perfectly here but requires very little interop by 
comparison.

What libraries are you using and what exactly is your link line?

The situation may have improved since then. We have binary demos for x86 and 
x86-64 Linux on our site:

  http://www.ffconsultancy.com/products/smoke_vector_graphics/demo1.html
  http://www.ffconsultancy.com/products/smoke_vector_graphics/demo2.html
  http://www.ffconsultancy.com/products/smoke_vector_graphics/tiger.html

I'd be interested to hear if anyone can run the bytecode version of Smoke or 
these binaries. I'll put Mac OS X and Windows ones up ASAP.

If anyone has any ideas of how this might be improved I'd love to hear them!

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Floating exception

[Vu Ngoc San]

>   http://www.ffconsultancy.com/products/smoke_vector_graphics/demo1.html
>   http://www.ffconsultancy.com/products/smoke_vector_graphics/demo2.html
>   http://www.ffconsultancy.com/products/smoke_vector_graphics/tiger.html
>
> I'd be interested to hear if anyone can run the bytecode version of Smoke
> or these binaries. I'll put Mac OS X and Windows ones up ASAP.


I ran your tiger demo on my linux machine (d630/kubuntu).
It worked very well for a couple of minutes. But then, as I was playing with 
resizing the window, my xserver crashed badly (black screen, trying to start 
X every 2 secs without success. Had to restart with Alt+Syst combination).

I must say I had the same problem with an application of my own using opengl. 
I thought it was due to a buggy gtkgl library... but since you don't use 
it... now I don't know.

San

Re: [Caml-list] Floating exception

[Vu Ngoc San]

Le Saturday 24 November 2007 23:36:24 Jon Harrop, vous avez écrit :

>
> I tried to reply to this on-list but my response hasn't appeared. Can you
> try compiling the free bytecode version from:
>
>   http://www.ffconsultancy.com/products/smoke_vector_graphics/free.html
>

I'm sorry I can't because kubuntu gutsy is shipped with ocaml 3.09.2
and you provide 3.09.1.

So I get:

Files graphics2D.cma(Utility) and /usr/lib/ocaml/3.09.2/stdlib.cma(Array)
make inconsistent assumptions over interface Array


> and let me know if that suffers from the same problem? Assuming that works
> then my theory is that the problem lies with compiling against lablgl on my
> machine, though I've no idea why.
>
> Many thanks,

Re: [Caml-list] Smoke on 3.09.2

[Jon Harrop]

On Sunday 25 November 2007 08:26, Vu Ngoc San wrote:
> Le Saturday 24 November 2007 23:36:24 Jon Harrop, vous avez écrit :
> > I tried to reply to this on-list but my response hasn't appeared. Can you
> > try compiling the free bytecode version from:
> >
> >   http://www.ffconsultancy.com/products/smoke_vector_graphics/free.html
>
> I'm sorry I can't because kubuntu gutsy is shipped with ocaml 3.09.2
> and you provide 3.09.1.
>
> So I get:
>
> Files graphics2D.cma(Utility) and /usr/lib/ocaml/3.09.2/stdlib.cma(Array)
> make inconsistent assumptions over interface Array

Sorry, I was working on the assumption that OCaml only breaks compatibility on 
minor updates. I'll install 3.09.2 and build a free edition of Smoke just for 
you. :-)

Is it really necessary for OCaml to break compatibility on minor-minor 
releases like this?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Smoke on 3.09.2

[Jon Harrop]

On Sunday 25 November 2007 15:35, Jon Harrop wrote:
> Sorry, I was working on the assumption that OCaml only breaks compatibility
> on minor updates. I'll install 3.09.2 and build a free edition of Smoke
> just for you. :-)

All done. Please try the new free edition of Smoke for OCaml 3.09.2:

  http://www.ffconsultancy.com/products/smoke_vector_graphics/free.html

Let's see if that fixes the crashing problem...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Smoke on 3.09.2

[Vu Ngoc San]

Le Sunday 25 November 2007 19:26:17 Jon Harrop, vous avez écrit :
> On Sunday 25 November 2007 15:35, Jon Harrop wrote:
> > Sorry, I was working on the assumption that OCaml only breaks
> > compatibility on minor updates. I'll install 3.09.2 and build a free
> > edition of Smoke just for you. :-)
>
> All done. Please try the new free edition of Smoke for OCaml 3.09.2:
>
>   http://www.ffconsultancy.com/products/smoke_vector_graphics/free.html
>
> Let's see if that fixes the crashing problem...


Thanks, now it builds fine. And I really thought the problem was gone; After 
resizing the window madly, I was just trying to anwser that everything was ok 
when it suddenly froze exactly as before. :-(

It's maybe a bug of my video driver (xorg-intel). However, I tried to  
reproduce it with glxgears and I couldn't.

Btw: I don't know if it is useful or not, but your 'clicking and zooming' in 
the tiger demo is quite nice

Re: [Caml-list] Smoke on 3.09.2

[Jon Harrop]

On Sunday 25 November 2007 20:12, Vu Ngoc San wrote:
> Thanks, now it builds fine. And I really thought the problem was gone;
> After resizing the window madly, I was just trying to anwser that
> everything was ok when it suddenly froze exactly as before. :-(
>
> It's maybe a bug of my video driver (xorg-intel). However, I tried to
> reproduce it with glxgears and I couldn't.

Ok. That was a common problem cited by our users before, particularly with 
regard to ATi cards rather than Intel. Perhaps nVidia cards should be a 
requirement under Linux. Hopefully Mac OS X can handle all of the cards that 
it supports.

Have you tried using software rendering via Mesa rather than xorg-intel?

Do you use any other OpenGL software on a regular basis?

> Btw: I don't know if it is useful or not, but your 'clicking and zooming'
> in the tiger demo is quite nice

Yes. Smoke is based upon the hierarchical decomposition of vector scenes into 
non-overlapping tesselations that can be cached on the graphics card. This 
underpins its performance, which is typically an order of magnitude faster 
than Cairo, Adobe Flash or Microsoft Silverlight. Consequently, Smoke is 
ideal for building responsive vector GUIs and OCaml makes it a dream to work 
with.

We've been sitting on the OCaml implementation of Smoke for several years and 
problems like these are preventing us from commercializing it successfully. 
This is a great shame because OCaml is an excellent language for graphics 
programming. I believe the best solution would be an OpenGL-enabled OCaml VM.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Smoke on 3.09.2

[Vu Ngoc San]

> Have you tried using software rendering via Mesa rather than xorg-intel?

not on this machine (it's a new one, I haven't done many experiments yet)
>
> Do you use any other OpenGL software on a regular basis?
>
I guess yet. compiz (except when running another opengl application; they 
don't mix well). Also, I play armagetronad quite a bit :-)
And of course, my own small ocaml software...

Have you experimented with glcaml ? I was tempted to give it a try.

Re: [Caml-list] Smoke on 3.09.2

[Jon Harrop]

On Sunday 25 November 2007 21:20, Vu Ngoc San wrote:
> I guess yet. compiz (except when running another opengl application; they
> don't mix well). Also, I play armagetronad quite a bit :-)
> And of course, my own small ocaml software...

Hmm, ok. And is it particularly resizing windows that causes the problem?

> Have you experimented with glcaml ? I was tempted to give it a try.

Not yet but it looks extremely promising. A shim that provided stronger type 
checking (as LablGL does) would be very useful.

Does glcaml support GLU?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Floating exception

[Sebastien Ferre]

Hi,

I've got the same problem with the simplest program,
the "hello world" :

let _ = print_string "Hello world!\n"


* Machine where compiled (in native code):

Linux version 2.6.20-1.2952.fc6 
(brewbuilder@ls20-bc1-14.build.redhat.com) (gcc
version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:59:18 
EDT 2007
Intel(R) Core(TM) Duo CPU      U2500  @ 1.20GHz


* Machine where execution produces "Floating exception"

Linux version 2.6.15-1.1833_FC4smp 
(bhcompile@hs20-bc1-1.build.redhat.com) (gcc
version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 SMP Wed Mar 1 23:56:51 EST 2006
Intel(R) Xeon(TM) CPU 3.40GHz

I know I cannot assume that a native binary is portable,
but I'd like to understand what makes it fail.
gcc version, redhat version, FC version ?


Sebastien

Kim Nguyen wrote:
> On Fri, 2007-11-23 at 19:08 +0100, Sebastien Ferre wrote:
>> Hi,
>>
>> I compiled an OCaml program in native code on
>> my new Linux machine. It runs without problem on
>> this machine, but crashes as soon as it is executed
>> with "Floating exception" on another Linux machine.
>> The 2 machines have a similar processors (Intel Core Duo
>> and Intel Xeon).
>>
>> What puzzles me is that it was working properly
>> with my previous machine, which was very similar
>> to the new one (Dell D400 -> D420).
>> Another change is that I shifted from OCaml 3.08
>> to OCaml 3.09.
>>
>> Does anybody have an idea of the cause of such an
>> obscure error ? and how to solve it ? :-)
> 
> Hello,
> 
> 	just my 2 cents but if you want useful feedback 
> (or any feedback at all) on your issue, you need to be more specific.
> What would help:
> - what your program does
> - what libraries it is linked to (with their version too)
> - your hardware (e.g. your graphic card if your program uses opengl...)
> - your distro, its version and its flavour (for both systems e.g. Ubuntu
> Gutsy amd64).
> - which version of OCaml and how it was installed (via packages, via
> godi, by hand,...).
> - maybe which drivers your are using if it is relevant (again if you use
> opengl, misbehaviour can be caused by many things: drivers, X, opengl
> libs, interaction between drivers and your kernel, use of a compositing
> manager such as compiz,...)
>  
> - Maybe a stripped down, minimal code sample which reproduces your bug
> (if possible).
> 
> Hopefully by gathering all this you will spot the bug yourself :-).
> If not then you can ask the list again, with the relevant information.
> 
> Hope this helps,

Re: [Caml-list] Floating exception

[Dmitry Bely]

On Nov 26, 2007 8:25 PM, Sebastien Ferre <Sebastien.Ferre@irisa.fr> wrote:

> I've got the same problem with the simplest program,
> the "hello world" :
>
> let _ = print_string "Hello world!\n"
>
>
> * Machine where compiled (in native code):
>
> Linux version 2.6.20-1.2952.fc6
> (brewbuilder@ls20-bc1-14.build.redhat.com) (gcc
> version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:59:18
> EDT 2007
> Intel(R) Core(TM) Duo CPU      U2500  @ 1.20GHz
>
>
> * Machine where execution produces "Floating exception"

It could be Ocaml runtime initialization. I've faced it under Windows
then loaded Ocaml DLL from Borland C-compiled program. The problem was
that Pervasives.infinity

let infinity =
  float_of_bits 0x7F_F0_00_00_00_00_00_00L

expects (due to float_of_bits) FP control word to be set some specific
way otherwise floating-point exception will occur. I worked around it
as follows:

      const unsigned newState =_EM_DENORMAL|
          _EM_INEXACT|_EM_UNDERFLOW|_EM_OVERFLOW|EM_ZERODIVIDE|_EM_INVALID;
      unsigned oldState = _control87(newState, _MCW_EM);
      caml_startup(argv);
      _control87(oldState, _MCW_EM);

(Don't remember which flags are really necessary - I just duplicated
the default MSVC compiler state that worked)

Probably this is Ocaml bug as its runtime should not depend on the
default state of FP control word and should set in explicitly.

- Dmitry Bely

Re: [Caml-list] Floating exception

[Richard Jones]

On Mon, Nov 26, 2007 at 06:25:51PM +0100, Sebastien Ferre wrote:
> I've got the same problem with the simplest program,
> the "hello world" :
> 
> let _ = print_string "Hello world!\n"
> 
> * Machine where compiled (in native code):
> 
> Linux version 2.6.20-1.2952.fc6 
> (brewbuilder@ls20-bc1-14.build.redhat.com) (gcc
> version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:59:18 
> EDT 2007
> Intel(R) Core(TM) Duo CPU      U2500  @ 1.20GHz
> 
> 
> * Machine where execution produces "Floating exception"
> 
> Linux version 2.6.15-1.1833_FC4smp 
> (bhcompile@hs20-bc1-1.build.redhat.com) (gcc
> version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 SMP Wed Mar 1 23:56:51 EST 2006
> Intel(R) Xeon(TM) CPU 3.40GHz
> 
> I know I cannot assume that a native binary is portable,
> but I'd like to understand what makes it fail.
> gcc version, redhat version, FC version ?

Are you using the Fedora ocaml or did you compile it yourself, and
which version of OCaml is this?  I've shipped binaries of native OCaml
programs to a lot of customers and no one has reported anything like
this (which is not to say it can't happen).

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Floating exception

[Sebastien Ferre]

Richard Jones wrote:
> On Mon, Nov 26, 2007 at 06:25:51PM +0100, Sebastien Ferre wrote:
>> I've got the same problem with the simplest program,
>> the "hello world" :
>>
>> let _ = print_string "Hello world!\n"
>>
>> * Machine where compiled (in native code):
>>
>> Linux version 2.6.20-1.2952.fc6 
>> (brewbuilder@ls20-bc1-14.build.redhat.com) (gcc
>> version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:59:18 
>> EDT 2007
>> Intel(R) Core(TM) Duo CPU      U2500  @ 1.20GHz
>>
>>
>> * Machine where execution produces "Floating exception"
>>
>> Linux version 2.6.15-1.1833_FC4smp 
>> (bhcompile@hs20-bc1-1.build.redhat.com) (gcc
>> version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 SMP Wed Mar 1 23:56:51 EST 2006
>> Intel(R) Xeon(TM) CPU 3.40GHz
>>
>> I know I cannot assume that a native binary is portable,
>> but I'd like to understand what makes it fail.
>> gcc version, redhat version, FC version ?
> 
> Are you using the Fedora ocaml or did you compile it yourself, and
> which version of OCaml is this?  I've shipped binaries of native OCaml
> programs to a lot of customers and no one has reported anything like
> this (which is not to say it can't happen).

I compiled it myself, version 3.09.3.

(I used to ship native binaries too before, but this
was with OCaml 3.08.?, and Fedora Core 2).

Sebastien

Re: [Caml-list] Floating exception

[Jean-Marc EBER]

Could you please elaborate ?
Afer many years of industrial use and commercial distribution of OCaml generated 
binaries especially in the Win32 world (our clients run our software that 
includes non trivial bindings to external C routines on many different versions 
of Windows and hardware configurations), we could not notice this buggy behaviour.

Jean-Marc Eber


Jon Harrop a écrit :
> 
> Too many of our users found the binary generated by ocamlopt to be unusably 
> unreliable, typically due to random segfaulting that we could not reproduce. 

Re: [Caml-list] Floating exception

[Jon Harrop]

On Tuesday 27 November 2007 10:24, you wrote:
> Jon Harrop a écrit :
> > Too many of our users found the binary generated by ocamlopt to be
> > unusably unreliable, typically due to random segfaulting that we could
> > not reproduce.
>
> Could you please elaborate ?

There isn't really anything more that I can add. We wrote the OCaml the 
obvious way (no unsafe code) and used the conventional bindings (LablGL) and 
distributed the binary, only to find that too many people had reliability 
problems for it to be a viable product so we pulled it.

Now we're trying to give it away in bytecode form and even that is a major 
PITA because we need to install and compile against (including dependencies) 
several different minor-minor versions of OCaml just to garner enough 
interest to find out (from the only person who has given us feedback having 
managed to compile it out of 75 downloads so far this month) that even these 
trivial demos don't work.

My guess is that the glut libraries installed on these computers are causing 
the problems. Perhaps we should write bindings to GLX or use LablGTK2 to 
evade glut and see what happens but, of course, we cannot reproduce the 
problem here and there are a huge number of variations we could try without 
having any real idea of what is going wrong.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Floating exception

[Jean-Marc EBER]

I understand from your mail that the problem source is probably linked to the 
graphics part (either the OCaml binding or the OpenGL implementation itself) and 
not to OCaml's code generation or "binary production" feature. This confirms my 
intuition.

Jean-Marc



Jon Harrop a écrit :
> On Tuesday 27 November 2007 10:24, you wrote:
>> Jon Harrop a écrit :
>>> Too many of our users found the binary generated by ocamlopt to be
>>> unusably unreliable, typically due to random segfaulting that we could
>>> not reproduce.
>> Could you please elaborate ?
> 
> There isn't really anything more that I can add. We wrote the OCaml the 
> obvious way (no unsafe code) and used the conventional bindings (LablGL) and 
> distributed the binary, only to find that too many people had reliability 
> problems for it to be a viable product so we pulled it.
> 
> Now we're trying to give it away in bytecode form and even that is a major 
> PITA because we need to install and compile against (including dependencies) 
> several different minor-minor versions of OCaml just to garner enough 
> interest to find out (from the only person who has given us feedback having 
> managed to compile it out of 75 downloads so far this month) that even these 
> trivial demos don't work.
> 
> My guess is that the glut libraries installed on these computers are causing 
> the problems. Perhaps we should write bindings to GLX or use LablGTK2 to 
> evade glut and see what happens but, of course, we cannot reproduce the 
> problem here and there are a huge number of variations we could try without 
> having any real idea of what is going wrong.
> 

Re: [Caml-list] Floating exception

[Richard Jones]

On Tue, Nov 27, 2007 at 11:19:25AM +0000, Jon Harrop wrote:
> There isn't really anything more that I can add. We wrote the OCaml the 
> obvious way (no unsafe code) and used the conventional bindings (LablGL) and 
> distributed the binary, only to find that too many people had reliability 
> problems for it to be a viable product so we pulled it.

It does sound like the bindings or GL implementations are to blame.
virt-top is used by an indeterminate number of people, as a binary,
and I've not had any reports like this.  It does plenty of floating
point, it's native code, and compiled in the usual way.

> Now we're trying to give it away in bytecode form and even that is a major 
> PITA because we need to install and compile against (including dependencies) 
> several different minor-minor versions of OCaml just to garner enough 
> interest to find out (from the only person who has given us feedback having 
> managed to compile it out of 75 downloads so far this month) that even these 
> trivial demos don't work.

In Fedora I instituted a system of rigorous dependencies so that
binary RPMs can't be installed if they were built against the wrong
OCaml.  Doesn't help you though :-(

# rpm -q --requires ocaml-csv
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(VersionedDependencies) <= 3.0.3-1
libc.so.6()(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libc.so.6(GLIBC_2.4)(64bit)  
libdl.so.2()(64bit)  
libdl.so.2(GLIBC_2.2.5)(64bit)  
libm.so.6()(64bit)  
libm.so.6(GLIBC_2.2.5)(64bit)  
ocaml(Array) = aa8e3cd5824f9bb40b93fcd38d0c95b5
ocaml(Buffer) = f6cef633ea14963b84b79c4095c63dc3
ocaml(Enum) = c16e527384c2b6d71d8b19582503f5f1
ocaml(ExtList) = f0f729e9c5635a8010fc862a9c31fed4
ocaml(Obj) = 5cfae708052c692ea39d23ed930fd64d
ocaml(Pervasives) = 8ba3d1faa24d659525c9025f41fd0c57
ocaml(Printf) = 5dbbf45a03b54e6dbfcf39178d0d6341
ocaml(String) = 2c162ab314b2f0a2cfd22d471b2e21ab
ocaml(runtime) = 3.10.0

> My guess is that the glut libraries installed on these computers are causing 
> the problems. Perhaps we should write bindings to GLX or use LablGTK2 to 
> evade glut and see what happens but, of course, we cannot reproduce the 
> problem here and there are a huge number of variations we could try without 
> having any real idea of what is going wrong.

Do you remember if the crashes happened at predictable places (for
your customers) or were they random each time the program ran?

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Floating exception

[Jon Harrop]

On Tuesday 27 November 2007 15:35, Richard Jones wrote:
> On Tue, Nov 27, 2007 at 11:19:25AM +0000, Jon Harrop wrote:
> > There isn't really anything more that I can add. We wrote the OCaml the
> > obvious way (no unsafe code) and used the conventional bindings (LablGL)
> > and distributed the binary, only to find that too many people had
> > reliability problems for it to be a viable product so we pulled it.
>
> It does sound like the bindings or GL implementations are to blame.

GL works on these computers from programs not written in OCaml.

> virt-top is used by an indeterminate number of people, as a binary,
> and I've not had any reports like this.  It does plenty of floating
> point, it's native code, and compiled in the usual way.

Do you have statistics for any OpenGL-based OCaml programs?

> > My guess is that the glut libraries installed on these computers are
> > causing the problems. Perhaps we should write bindings to GLX or use
> > LablGTK2 to evade glut and see what happens but, of course, we cannot
> > reproduce the problem here and there are a huge number of variations we
> > could try without having any real idea of what is going wrong.
>
> Do you remember if the crashes happened at predictable places (for
> your customers) or were they random each time the program ran?

Random.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Floating exception

[Vu Ngoc San]

> My guess is that the glut libraries installed on these computers are
> causing the problems. Perhaps we should write bindings to GLX or use
> LablGTK2 to evade glut and see what happens but, of course, we cannot
> reproduce the problem here and there are a huge number of variations we
> could try without having any real idea of what is going wrong.


I wouldn't bet on this. I can reproduce the same bug with both the sdl-gl 
(ocamlsdl)  interface, and the gtk-gl (liblablgtk2-gl-ocaml) interface.

However, as I said, I couldn't with glxgears, and more interestingly I 
couldn't either with the demos shipped with glcaml. They use SDL. I just 
modified the source code in order to allow resizing windows.

Re: [Caml-list] Floating exception

[Jon Harrop]

On Wednesday 28 November 2007 10:47, Vu Ngoc San wrote:
> > My guess is that the glut libraries installed on these computers are
> > causing the problems. Perhaps we should write bindings to GLX or use
> > LablGTK2 to evade glut and see what happens but, of course, we cannot
> > reproduce the problem here and there are a huge number of variations we
> > could try without having any real idea of what is going wrong.
>
> I wouldn't bet on this. I can reproduce the same bug with both the sdl-gl
> (ocamlsdl)  interface, and the gtk-gl (liblablgtk2-gl-ocaml) interface.
>
> However, as I said, I couldn't with glxgears, and more interestingly I
> couldn't either with the demos shipped with glcaml. They use SDL. I just
> modified the source code in order to allow resizing windows.

Oh, this is very interesting. Let's try to narrow down the problem. The 
following don't work reliably for you:

OCaml -> LablGL -> Lablglut -> OpenGL
OCaml -> LablGL -> LablGTKGL -> OpenGL
OCaml -> LablGL -> OCamlSDL -> OpenGL

but the following do work:

OCaml -> GLCaml -> SDL + OpenGL
C -> GLX + OpenGL

Looks like the problem is with LablGL then?

Smoke actually makes relatively few OpenGL calls (most are done by GLU) so I 
can easily port it to GLCaml. Maybe I should try that next...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Floating exception

[Vu Ngoc San]

Le Wednesday 28 November 2007 11:47:16 Vu Ngoc San, vous avez écrit :
> > My guess is that the glut libraries installed on these computers are
> > causing the problems. Perhaps we should write bindings to GLX or use
> > LablGTK2 to evade glut and see what happens but, of course, we cannot
> > reproduce the problem here and there are a huge number of variations we
> > could try without having any real idea of what is going wrong.
>
> I wouldn't bet on this. I can reproduce the same bug with both the sdl-gl
> (ocamlsdl)  interface, and the gtk-gl (liblablgtk2-gl-ocaml) interface.
>
> However, as I said, I couldn't with glxgears, and more interestingly I
> couldn't either with the demos shipped with glcaml. They use SDL. I just
> modified the source code in order to allow resizing windows.
>
> _______________________________________________
> 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

don't blame lablgl too fast... in fact I finally WAS able to reproduce the bug 
with one of the glcaml demos, compiled to native code... (this time by moving 
the window around, instead of resizing). So I guess this is rather an issue 
with the xorg driver... and probably nothing ocaml-related.