Re: [Caml-list] Crashing X.Org with lablgl

Re: [Caml-list] Crashing X.Org with lablgl

[David Thomas]

--- Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
wrote:

> From: David Thomas <david_hd@yahoo.com>
> 
> > > Sending me the complete source to try to
> > > reproduce the problem?
> > 
> > ftp://tirnanogth.dyndns.org/pub/mrlplot.tar.gz
> 
> Thanks, but how can I reproduce the problem?
> The included datafile is empty, so I don't even now
> the format...

Updated with a proper datafile.  The program should be
run as:

mrlplot -file datafile

On every system where I've seen it crash, it's
predictably crashed within about a minute of starting,
although it does not seem to be a a fixed interval.

As to the program in general, rotate with the mouse or
with WASDQ and E, use ESC to quit.

> But Erik seems to be very competent on both openGL
> and lablGL, while I'm only on the second, so he
might 
> help you better if this is not a lablGL problem 
> proper.

Alright.
 
> By the way there's something slightly strange in
> your Makefile: you have -I +lablgl and -I +lablglut,

> while on a standard installation this should be only

> a single -I +lablGL. 

Hmm... seems to work either way, I'll use that one
going forward.

> What version are you using?  And as other suggested,

> what version of X.org. I remember that some version 
> had a compatibility problem gtkglarea, but then this

> is not what you are using.

Ocaml version 3.08.3
X.org version 7.1


 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

Re: [Caml-list] Crashing X.Org with lablgl

[Gerd Stolpmann]

Am Sonntag, den 25.02.2007, 23:39 -0800 schrieb David Thomas:
> Updated with a proper datafile.  The program should be
> run as:
> 
> mrlplot -file datafile

Can't reproduce the crash (X.org 7.0.0, i810 driver, Linux 2.6.15).

> > What version are you using?  And as other suggested,
> 
> > what version of X.org. I remember that some version 
> > had a compatibility problem gtkglarea, but then this
> 
> > is not what you are using.
> 
> Ocaml version 3.08.3
> X.org version 7.1

I think it can also depend on the driver you are using, and the kernel
version (direct rendering needs kernel support).

Anyway, this seems to be a non-ocaml bug.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: [Caml-list] Crashing X.Org with lablgl

[Erik de Castro Lopo]

David Thomas wrote:

> ftp://tirnanogth.dyndns.org/pub/mrlplot.tar.gz

Oh, cool!

> Updated with a proper datafile.  The program should be
> run as:
> 
> mrlplot -file datafile
> 
> On every system where I've seen it crash, it's
> predictably crashed within about a minute of starting,
> although it does not seem to be a a fixed interval.

I really hammered it, but no crash here on Ubuntu Feisty with 
Xorg 7.2. However, it seems that Edgy (the one I had trouble 
with) has Xorg 7.1. I didn't run Xorg 7.1 long enough do any
OpenGL hackingor testing because my window manager kept crashing.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Within C++, there is a much smaller and cleaner language struggling
to get out." -- Bjarne Stroustrup

Re: [Caml-list] Crashing X.Org with lablgl

[David Thomas]

--- Gerd Stolpmann <info@gerd-stolpmann.de> wrote:

> Am Sonntag, den 25.02.2007, 23:39 -0800 schrieb
> David Thomas:
> > Updated with a proper datafile.  The program
> > should be run as:
> > 
> > mrlplot -file datafile
> 
> Can't reproduce the crash (X.org 7.0.0, i810 driver,
> Linux 2.6.15).

Good to know, thanks :)
 
> > > What version are you using?  And as other
> > > suggested, what version of X.org. I remember
that 
> > > some version had a compatibility problem 
> > > gtkglarea, but then this is not what you are 
> > > using.
> > 
> > Ocaml version 3.08.3
> > X.org version 7.1
> 
> I think it can also depend on the driver you are
> using, and the kernel version (direct rendering
needs
> kernel support).

Hmm... the computers in question are running kernel
2.6.15, but don't have DRI support enabled (any of
them, working or not).
 
> Anyway, this seems to be a non-ocaml bug.

Seeming that way, yeah.


 
____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

Re: [Caml-list] Crashing X.Org with lablgl

[David Thomas]

--- Erik de Castro Lopo <mle+ocaml@mega-nerd.com>
wrote: 

> I really hammered it, but no crash here on Ubuntu
> Feisty with Xorg 7.2. However, it seems that Edgy 
> (the one I had trouble with) has Xorg 7.1. I didn't 
> run Xorg 7.1 long enough do any OpenGL hackingor 
> testing because my window manager kept crashing.

Sounds like Xorg 7.1 is just pretty unstable...  I'll
see about getting us off of it.


 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

Re: [Caml-list] Crashing X.Org with lablgl

[Vu Ngoc San]

[sorry for off-topic]

right, I should give it a try. At some point I had to patch nvidia 
sources in order to get suspend-to-disk working, and that was easier 
with the nvidia installer. Now the patch is not needed anymore...

San


Conrad Hughes a écrit :
> [slightly off-topic, but:]
> 
> Vu Ngoc San> I install manually the nvidia driver with
> Vu Ngoc San> ./NVIDIA-Linux-x86-1.0-8756-pkg1.run
> [..]
> Vu Ngoc San> I suspect that debian packages overwrite some libs that become 
> Vu Ngoc San> incompatible with my nvidia kernel installation.
> 
> More the other way around, but yes, the NVIDIA driver binary install
> even explicitly mentions that it overwrites some original X install
> files.  Why don't you use the official Debian NVIDIA packages?  1.0-8776
> is in testing and unstable, and 1.0.9746 is in experimental.  If you
> want to run stable and are not familiar with mixing in bits from other
> versions of Debian, you should read "man apt_preferences" for a start.
> Adding (say) experimental to your sources.list, and something like
> 
>   Package: nvidia-*
>   Pin: release o=Debian,a=experimental
>   Pin-Priority: 991
> 
> to your /etc/apt/preferences should get you going.
> 
> Conrad
> 


-- 
---
Vu Ngoc San			tel:04 76 63 58 53
Institut Fourier		e-mail:San.Vu-Ngoc@ujf-grenoble.fr
Universite Grenoble 1, BP 74	http://www-fourier.ujf-grenoble.fr/~svungoc
38402 Saint Martin d'Heres
France
---

Re: [Caml-list] Crashing X.Org with lablgl

[David Thomas]

--- Jon Harrop <jon@ffconsultancy.com> wrote:

> On Monday 26 February 2007 05:51, Daniel Bünzli
> wrote:
> > There are things that are off-limits to lablgl's
> > type safety, for example on osx a call to any 
> > opengl function before a rendering context has
been
> > created just crashes the program.
> > 
> > Did you try to call Gl.raise_error in your 
> > rendering loop to be sure you are not
> > doing something wrong with opengl ?
> 
> The order of initialisation calls can cause
> segfaults on some machines.

Segfaults in the application, or segfaults in the X
server?

> I did some fairly extensive testing before we
> released Presenta. Around 10% of machines crashed 
> OpenGL binaries that were moved onto them.
> 
> If you want portable (between machines) 3D then try
> F#, .NET and managed 
> DirectX.

These were built on the machines running them.


 
____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.

Re: [Caml-list] Crashing X.Org with lablgl

[Conrad Hughes]

[slightly off-topic, but:]

Vu Ngoc San> I install manually the nvidia driver with
Vu Ngoc San> ./NVIDIA-Linux-x86-1.0-8756-pkg1.run
[..]
Vu Ngoc San> I suspect that debian packages overwrite some libs that become 
Vu Ngoc San> incompatible with my nvidia kernel installation.

More the other way around, but yes, the NVIDIA driver binary install
even explicitly mentions that it overwrites some original X install
files.  Why don't you use the official Debian NVIDIA packages?  1.0-8776
is in testing and unstable, and 1.0.9746 is in experimental.  If you
want to run stable and are not familiar with mixing in bits from other
versions of Debian, you should read "man apt_preferences" for a start.
Adding (say) experimental to your sources.list, and something like

  Package: nvidia-*
  Pin: release o=Debian,a=experimental
  Pin-Priority: 991

to your /etc/apt/preferences should get you going.

Conrad

Re: [Caml-list] Crashing X.Org with lablgl

[Jon Harrop]

On Monday 26 February 2007 11:23, you wrote:
> It's definitively not an issue, OpenGL ABI is stable.
> You can have problem on executing on the same machine with a random
> quality driver.

In my experience, compiling and executing on the same machine is far more 
robust (>99%) than moving between machines (~90%). Also, we're not just 
talking about OpenGL versions (which change regularly) but also GLU, 
glut/freeglut, (potentially) SDL, the linker and compiler as well as platform 
issues (e.g. 32-bit chroots).

Problems often boil down to glut vs freeglut so I'd start there. I'm not sure 
what the solution is though. We really need just one decent glut-like 
library, complete bindings to it from OpenGL and safe high-level bindings. 
I'm a little disheartened that nobody replied to my post about GLCaml.

Anyway, I'm writing the equivalent for F# right now... :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Crashing X.Org with lablgl

[Vu Ngoc San]

I'm talking about nvidia and opengl and debian. nothing ocaml specific.

Let me be more precise:

I install manually the nvidia driver with
./NVIDIA-Linux-x86-1.0-8756-pkg1.run

Then everything runs fine. (I compile and execute on the same machine)

when there is an upgrade of some xorg component in debian unstable,
then, after apt-get upgrade, glx is very often broken.
Just running glxgears crashes the x server. Sometimes also a more subtle 
effect of this is that glxgears display becomes very slow, or hectic.

I suspect that debian packages overwrite some libs that become 
incompatible with my nvidia kernel installation. I'm saying this because 
usually it is enough to copy again the files created by the nvidia 
installer and it works again. But sometimes I have to recompile the 
nvidia drivers.

Again, nothing ocaml specific here. For me lablgl works like a charm
(except that I had to patch it by hand in order to have the 
polygon_offset feature and (thanks to Jacques Garrigue), the feedback 
features)


San

Re: [Caml-list] Crashing X.Org with lablgl

[Vincent Hanquez]

On Mon, Feb 26, 2007 at 10:47:11AM +0000, Jon Harrop wrote:
> On Monday 26 February 2007 08:01, Vu Ngoc San wrote:
> > Well I've used lablgl with a debian box (unstable) and X.org quite a
> > bit, without problem. (with both glut and sdl)
> 
> Did you compile on one machine and execute on another? I've never had
> problems compiling and executing on the same machine...

It's definitively not an issue, OpenGL ABI is stable.
You can have problem on executing on the same machine with a random
quality driver.

-- 
Vincent Hanquez

Re: [Caml-list] Crashing X.Org with lablgl

[Jon Harrop]

On Monday 26 February 2007 08:01, Vu Ngoc San wrote:
> Well I've used lablgl with a debian box (unstable) and X.org quite a
> bit, without problem. (with both glut and sdl)

Did you compile on one machine and execute on another? I've never had problems 
compiling and executing on the same machine...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Crashing X.Org with lablgl

[Vu Ngoc San]

Well I've used lablgl with a debian box (unstable) and X.org quite a 
bit, without problem. (with both glut and sdl)
I did had some crash however each time there is a conflict between new 
debian packages and the proprietary nvidia driver. Since I use the 
latter, I have to recompile it separately each time there is an upgrade 
in debian.

San

Re: [Caml-list] Crashing X.Org with lablgl

[Jon Harrop]

On Monday 26 February 2007 05:51, Daniel Bünzli wrote:
> There are things that are off-limits to lablgl's type safety, for
> example on osx a call to any opengl function before a rendering
> context has been created just crashes the program. Did you try to
> call Gl.raise_error in your rendering loop to be sure you are not
> doing something wrong with opengl ?

The order of initialisation calls can cause segfaults on some machines.

I did some fairly extensive testing before we released Presenta. Around 10% of 
machines crashed OpenGL binaries that were moved onto them.

If you want portable (between machines) 3D then try F#, .NET and managed 
DirectX.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Crashing X.Org with lablgl

[David Thomas]

--- Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
wrote:
 
> 
> You should at least say which front-end you use for
> lablGL (Tcl/Tk, Glut or LablGTK). This may be 
> relevant.

Ah, yes.  I'm using Glut.

> > 1) I'm sure that there *shouldn't* be any sequence
> > of  calls to lablgl that should outright crash the
> > X server... does anyone know how true this proves 
> > in practice?
> 
> Well, if there is a bug in the X server, a program
> may trigger it. 

Yeah, that's my best guess for what's happening
here, too.

> Personally I've never seen that for lablGL though.
> And the reports I've seen were about the program
> itself segfaulting, not the server.

Interesting.

> > 2) Any thoughts as to how I can pinpoint the
> > problem a bit better?
> 
> Sending me the complete source to try to reproduce
> the problem?

ftp://tirnanogth.dyndns.org/pub/mrlplot.tar.gz

> You could also look at the features you are using:
> does turning double-buffering off change anything,
> are you using lots of display lists...

An interesting thought.  I'll try shuffling those a
bit, see if it does me any good.



 
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

Re: [Caml-list] Crashing X.Org with lablgl

[Daniel Bünzli]

Le 26 févr. 07 à 06:01, David Thomas a écrit :

> 1) I'm sure that there *shouldn't* be any sequence of
> calls to lablgl that should outright crash the X
> server... does anyone know how true this proves in
> practice?

There are things that are off-limits to lablgl's type safety, for  
example on osx a call to any opengl function before a rendering  
context has been created just crashes the program. Did you try to  
call Gl.raise_error in your rendering loop to be sure you are not  
doing something wrong with opengl ?

Daniel

Re: [Caml-list] Crashing X.Org with lablgl

[Jacques Garrigue]

From: David Thomas <david_hd@yahoo.com>
> Working on a 3d plotting program in ocaml, using
> lablgl.  I got it working on my laptop, which is
> running Debian 3.1, with XFree86.  All seemed to run
> fine.  
> 
> Moved it over to another box, it runs fine for about a
> minute before the X server segfaults.  Duplicated the
> result on three computers at work, all running X.Org
> under Debian. Works fine on another computer running
> XFree86.

You should at least say which front-end you use for lablGL (Tcl/Tk,
Glut or LablGTK). This may be relevant.

> 1) I'm sure that there *shouldn't* be any sequence of
> calls to lablgl that should outright crash the X
> server... does anyone know how true this proves in
> practice?

Well, if there is a bug in the X server, a program may trigger it.
Personally I've never seen that for lablGL though. And the reports
I've seen were about the program itself segfaulting, not the server.

> 2) Any thoughts as to how I can pinpoint the problem a
> bit better?

Sending me the complete source to try to reproduce the problem?

You could also look at the features you are using: does turning
double-buffering off change anything, are you using lots of display
lists...

> 3) Any suggestions for working around it?  Considering
> writing a simple library implementing the parts of
> lablgl that I need (which is relatively limited, as
> it's ultimately line-drawing), but that's not
> thrilling...

It might work. But would it not be simpler to write most of your display
code in C, and just the logic in ocaml. This way, if the same problem
pops up again you would have some C code to show the developpers.

Jacques Garrigue

Re: [Caml-list] Crashing X.Org with lablgl

[Erik de Castro Lopo]

David Thomas wrote:

> Unfortunately, others on the project (with more clout)
> are unwilling to move these systems back to XFree86.
> While there *is* a 100% correlation between
> X.Org/XFree86 and crashing/not, it's doubtful that
> this is the only thing that's different between the
> systems.

What version of X.org? I had a lot of trouble on the Edgy Eft
release of Ubuntu which had X.org 7.0. Those troubles disappeared
when I moved to Ubuntu Feisty which has X.org 7.2.

> I guess I've a few questions.  
> 
> 1) I'm sure that there *shouldn't* be any sequence of
> calls to lablgl that should outright crash the X
> server... does anyone know how true this proves in
> practice?

No, the xserver should not crash because of a user space
program.

> 2) Any thoughts as to how I can pinpoint the problem a
> bit better?

Try strace/ltracing the executable to pinpoint which call
to the underlying X libs are causing the crash, then write
(in C if possible) a minimal test program to recreate the
problem and send it as a bug report to the X maintainers.

If you're not up to writing the minimal C program but can
write a minimal Ocaml program I'd be happy to translate it
for you.

Hope this helps,
Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Projects promoting programming in natural language are intrinsically
doomed to fail." -- Edsger Dijkstra