Crashing X.Org with lablgl

Crashing X.Org with lablgl

[David Thomas]

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.

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.

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?

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

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

Would definately prefer not to have to ditch ocaml on
this one, so any suggestions will be greatly
appreciated.

Thanks in advance!


 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

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

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

[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

[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]

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

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

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

[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

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