www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DWT+OpenGL crashing on Vista

reply Bill Baxter <wbaxter gmail.com> writes:
I'm going crazy here with a very odd bug.
My DWT+OpenGL Win32 app is crashing *only* on Vista and *only* when I
use client arrays for rendering
(i.e. glEnableClientState(GL_VERTEX_ARRAY), glVertexPointer(...),
glArrayElement(....)).

The exact same code works fine on XP.
I have the Areo desktop compositing diabled on Vista.
The exact same code works fine if I replace the glArrayElement calls
with glVertex3fv calls.

Another weird thing is that it doesn't crash right away,   The thing
I'm drawing will draw fine for 20 or so frames, then it crashes,
usually in swapBuffers or in the glClear.after swapBuffers.
Sometimes the same program will not crash at all.

I tried modifying a DWT OpenGL snippet to use client arrays, but I
couldn't get it to crash.

I tried disabling the GC too,  no change.
A web search didn't turn up anyone else with similar problems.

I upgraded my video drivers (GeForce 8400M GS) with the latest from
NVIDIA, but still no change.

I just have no idea what else could be going wrong or what else I could try.

--bb
Jan 16 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 17 Jan 2009 02:51:46 +0300, Bill Baxter <wbaxter gmail.com> wrote:

 I'm going crazy here with a very odd bug.
 My DWT+OpenGL Win32 app is crashing *only* on Vista and *only* when I
 use client arrays for rendering
 (i.e. glEnableClientState(GL_VERTEX_ARRAY), glVertexPointer(...),
 glArrayElement(....)).

 The exact same code works fine on XP.
 I have the Areo desktop compositing diabled on Vista.
 The exact same code works fine if I replace the glArrayElement calls
 with glVertex3fv calls.

 Another weird thing is that it doesn't crash right away,   The thing
 I'm drawing will draw fine for 20 or so frames, then it crashes,
 usually in swapBuffers or in the glClear.after swapBuffers.
 Sometimes the same program will not crash at all.

 I tried modifying a DWT OpenGL snippet to use client arrays, but I
 couldn't get it to crash.

 I tried disabling the GC too,  no change.
 A web search didn't turn up anyone else with similar problems.

 I upgraded my video drivers (GeForce 8400M GS) with the latest from
 NVIDIA, but still no change.

 I just have no idea what else could be going wrong or what else I could  
 try.

 --bb
Looks like some kind of memory damage to me.
Jan 16 2009
prev sibling next sibling parent "Tim M" <a b.com> writes:
On Sat, 17 Jan 2009 12:51:46 +1300, Bill Baxter <wbaxter gmail.com> wrote:

 I'm going crazy here with a very odd bug.
 My DWT+OpenGL Win32 app is crashing *only* on Vista and *only* when I
 use client arrays for rendering
 (i.e. glEnableClientState(GL_VERTEX_ARRAY), glVertexPointer(...),
 glArrayElement(....)).

 The exact same code works fine on XP.
 I have the Areo desktop compositing diabled on Vista.
 The exact same code works fine if I replace the glArrayElement calls
 with glVertex3fv calls.

 Another weird thing is that it doesn't crash right away,   The thing
 I'm drawing will draw fine for 20 or so frames, then it crashes,
 usually in swapBuffers or in the glClear.after swapBuffers.
 Sometimes the same program will not crash at all.

 I tried modifying a DWT OpenGL snippet to use client arrays, but I
 couldn't get it to crash.

 I tried disabling the GC too,  no change.
 A web search didn't turn up anyone else with similar problems.

 I upgraded my video drivers (GeForce 8400M GS) with the latest from
 NVIDIA, but still no change.

 I just have no idea what else could be going wrong or what else I could  
 try.

 --bb
Just reading crashing on vista and couldn't help stop laughing. I dont really have a sollution but apply all updates, run in xp compatble mode. I tried searching for this and found: http://www.opengl.org/pipeline/article/vol003_9/ http://digitalmathom.blogspot.com/2007/05/opengl-on-vista-problem-solved.html http://www.technologyquestions.com/technology/vista-games/237715-sp1-breaks-opengl-apps-e-g-doom-3-a.html
Jan 16 2009
prev sibling parent reply "Tim M" <a b.com> writes:
On Sat, 17 Jan 2009 12:51:46 +1300, Bill Baxter <wbaxter gmail.com> wrote:

 I'm going crazy here with a very odd bug.
 My DWT+OpenGL Win32 app is crashing *only* on Vista and *only* when I
 use client arrays for rendering
 (i.e. glEnableClientState(GL_VERTEX_ARRAY), glVertexPointer(...),
 glArrayElement(....)).

 The exact same code works fine on XP.
 I have the Areo desktop compositing diabled on Vista.
 The exact same code works fine if I replace the glArrayElement calls
 with glVertex3fv calls.

 Another weird thing is that it doesn't crash right away,   The thing
 I'm drawing will draw fine for 20 or so frames, then it crashes,
 usually in swapBuffers or in the glClear.after swapBuffers.
 Sometimes the same program will not crash at all.

 I tried modifying a DWT OpenGL snippet to use client arrays, but I
 couldn't get it to crash.

 I tried disabling the GC too,  no change.
 A web search didn't turn up anyone else with similar problems.

 I upgraded my video drivers (GeForce 8400M GS) with the latest from
 NVIDIA, but still no change.

 I just have no idea what else could be going wrong or what else I could  
 try.

 --bb
I am actually very interested if you find the problem/sollution. If it's not D related can you email what you find about it to me: t i m <dot> m a t t h e w s 7 (at) g m a i l [dot] c o m Thanks.
Jan 17 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Sun, Jan 18, 2009 at 11:29 AM, Tim M <a b.com> wrote:
 On Sat, 17 Jan 2009 12:51:46 +1300, Bill Baxter <wbaxter gmail.com> wrote:

 I'm going crazy here with a very odd bug.
 My DWT+OpenGL Win32 app is crashing *only* on Vista and *only* when I
 use client arrays for rendering
 (i.e. glEnableClientState(GL_VERTEX_ARRAY), glVertexPointer(...),
 glArrayElement(....)).

 The exact same code works fine on XP.
 I have the Areo desktop compositing diabled on Vista.
 The exact same code works fine if I replace the glArrayElement calls
 with glVertex3fv calls.

 Another weird thing is that it doesn't crash right away,   The thing
 I'm drawing will draw fine for 20 or so frames, then it crashes,
 usually in swapBuffers or in the glClear.after swapBuffers.
 Sometimes the same program will not crash at all.

 I tried modifying a DWT OpenGL snippet to use client arrays, but I
 couldn't get it to crash.

 I tried disabling the GC too,  no change.
 A web search didn't turn up anyone else with similar problems.

 I upgraded my video drivers (GeForce 8400M GS) with the latest from
 NVIDIA, but still no change.

 I just have no idea what else could be going wrong or what else I could
 try.

 --bb
I am actually very interested if you find the problem/sollution. If it's not D related can you email what you find about it to me: t i m <dot> m a t t h e w s 7 (at) g m a i l [dot] c o m
So far haven't been able to isolate it. I updated another program that displays meshes with similar code and it works fine. So sounds like some kind of memory problem in my code to me too. Or possibly passing a bad pointer to GL somewhere. I have glGetError's sprinkled all over my code and get no errors from that. But GL doesn't know if you pass it a bad pointer. I remember one problem I had long ago when I called glGetIntegerv for something, thinking it returned 1 value when it actually returned two. Seems likely it could be something similar here. --bb
Jan 17 2009
parent reply Sergey Kovrov <kovrov+digitalmars gmail.com> writes:
On 1/18/2009 5:51 AM, Bill Baxter wrote:
 So far haven't been able to isolate it.
 I updated another program that displays meshes with similar code and
 it works fine.
 So sounds like some kind of memory problem in my code to me too.  Or
 possibly passing a bad pointer to GL somewhere.  I have glGetError's
 sprinkled all over my code and get no errors from that.  But GL
 doesn't know if you pass it a bad pointer.

 I remember one problem I had long ago when I called glGetIntegerv for
 something, thinking it returned 1 value when it actually returned two.
   Seems likely it could be something similar here.

 --bb
You could check if you have "wild" Client State somewhere ("wild" like in "wild pointers"). It is easy to forget to call glDisableClientState for some of GL_..._ARRAY capability when it no longer needed. And in such case error might manifest it self in an unusual way, just like in case of generic dangling pointers. -- serg.
Jan 18 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
Here's a modified version of one of the DWT opengl snippets that
reproduces the crash for me.
About 1 in 10-15 runs this will crash (seems to be inside the GL
driver) soon after startup with the error:

"""
dwt.DWTException.DWTException: Failed to execute runnable

object.Exception: Access Violation
"""

Can anyone else reproduce this (particularly Vista users)?
I'd be happy to send the exe to anyone who would like to try it off
list.  But it's a 3MB exe  (compresses to about .7 MB).

--bb

On Sun, Jan 18, 2009 at 11:35 PM, Sergey Kovrov
<kovrov+digitalmars gmail.com> wrote:
 On 1/18/2009 5:51 AM, Bill Baxter wrote:
 So far haven't been able to isolate it.
 I updated another program that displays meshes with similar code and
 it works fine.
 So sounds like some kind of memory problem in my code to me too.  Or
 possibly passing a bad pointer to GL somewhere.  I have glGetError's
 sprinkled all over my code and get no errors from that.  But GL
 doesn't know if you pass it a bad pointer.

 I remember one problem I had long ago when I called glGetIntegerv for
 something, thinking it returned 1 value when it actually returned two.
  Seems likely it could be something similar here.

 --bb
You could check if you have "wild" Client State somewhere ("wild" like in "wild pointers"). It is easy to forget to call glDisableClientState for some of GL_..._ARRAY capability when it no longer needed. And in such case error might manifest it self in an unusual way, just like in case of generic dangling pointers. -- serg.
Jan 18 2009
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 19 Jan 2009 07:17:16 +0900, Bill Baxter wrote:

 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:
 
 """
 dwt.DWTException.DWTException: Failed to execute runnable
 
 object.Exception: Access Violation
 """
 
 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
Yes I can. From the first try. I've got an XP Home laptop, core 2 duo at 1.83GHz, 1GB RAM, GeForce Go 7600. DWT is trunk r119. Derelict is trunk r308. The executable is 2MB, built in about 6.5s. It's almost 100% reproducible. I mean it worked only once out of ~30 tries.
Jan 18 2009
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Sergey,

 Mon, 19 Jan 2009 07:17:16 +0900, Bill Baxter wrote:
 
 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:
 """
 dwt.DWTException.DWTException: Failed to execute runnable
 object.Exception: Access Violation
 """
 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
Yes I can. From the first try. I've got an XP Home laptop, core 2 duo at 1.83GHz, 1GB RAM, GeForce Go 7600. DWT is trunk r119. Derelict is trunk r308.
I know this is off topic, but... That's almost a waste of the Core 2 running it on XP Home Editon, isn't it? I believe you need XP Pro to take advantage of the multi-core. -JJR
Jan 18 2009
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from John Reimer (terminal.node gmail.com)'s article
 Hello Sergey,
 Mon, 19 Jan 2009 07:17:16 +0900, Bill Baxter wrote:

 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:
 """
 dwt.DWTException.DWTException: Failed to execute runnable
 object.Exception: Access Violation
 """
 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
Yes I can. From the first try. I've got an XP Home laptop, core 2 duo at 1.83GHz, 1GB RAM, GeForce Go 7600. DWT is trunk r119. Derelict is trunk r308.
I know this is off topic, but... That's almost a waste of the Core 2 running it on XP Home Editon, isn't it? I believe you need XP Pro to take advantage of the multi-core. -JJR
Nope. I'm running an Athlon 64 X2 on XP home. Runs fine, sees both cores.
Jan 18 2009
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 19 Jan 2009 00:10:08 +0000 (UTC), John Reimer wrote:

 Hello Sergey,
 
 Mon, 19 Jan 2009 07:17:16 +0900, Bill Baxter wrote:
 
 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:
 """
 dwt.DWTException.DWTException: Failed to execute runnable
 object.Exception: Access Violation
 """
 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
Yes I can. From the first try. I've got an XP Home laptop, core 2 duo at 1.83GHz, 1GB RAM, GeForce Go 7600. DWT is trunk r119. Derelict is trunk r308.
I know this is off topic, but... That's almost a waste of the Core 2 running it on XP Home Editon, isn't it? I believe you need XP Pro to take advantage of the multi-core.
That depends on what you consider a waste. V-ray render utilizes both cores to 100% happily.
Jan 19 2009
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Sergey,

 Mon, 19 Jan 2009 00:10:08 +0000 (UTC), John Reimer wrote:
 
 Hello Sergey,
 
 Mon, 19 Jan 2009 07:17:16 +0900, Bill Baxter wrote:
 
 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:
 """
 dwt.DWTException.DWTException: Failed to execute runnable
 object.Exception: Access Violation
 """
 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
Yes I can. From the first try. I've got an XP Home laptop, core 2 duo at 1.83GHz, 1GB RAM, GeForce Go 7600. DWT is trunk r119. Derelict is trunk r308.
I know this is off topic, but... That's almost a waste of the Core 2 running it on XP Home Editon, isn't it? I believe you need XP Pro to take advantage of the multi-core.
That depends on what you consider a waste. V-ray render utilizes both cores to 100% happily.
No, I may have been wrong, I guess. I was just sure that XP Home didn't provide support for anything more than single processor/core use. -JJR
Jan 19 2009
parent reply Anders Bergh <anders1 gmail.com> writes:
On Mon, Jan 19, 2009 at 15:46, John Reimer <terminal.node gmail.com> wrote:
 No, I may have been wrong, I guess.  I was just sure that XP Home didn't
 provide support for anything more than single processor/core use.


 -JJR
It doesn't let you use more than one processor, but it's ok with multicore processors, you could even use a quad core with Home. -- Anders Bergh
Jan 21 2009
parent John Reimer <terminal.node gmail.com> writes:
Hello Anders,

 On Mon, Jan 19, 2009 at 15:46, John Reimer <terminal.node gmail.com>
 wrote:
 
 No, I may have been wrong, I guess.  I was just sure that XP Home
 didn't provide support for anything more than single processor/core
 use.
 
 -JJR
 
It doesn't let you use more than one processor, but it's ok with multicore processors, you could even use a quad core with Home.
Wow! I thought it treated cores as CPUS... that's very good to know, thanks. :) -JJR
Jan 21 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jan 19, 2009 at 8:53 AM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Mon, 19 Jan 2009 07:17:16 +0900, Bill Baxter wrote:

 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:

 """
 dwt.DWTException.DWTException: Failed to execute runnable

 object.Exception: Access Violation
 """

 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
Yes I can. From the first try. I've got an XP Home laptop, core 2 duo at 1.83GHz, 1GB RAM, GeForce Go 7600. DWT is trunk r119. Derelict is trunk r308. The executable is 2MB, built in about 6.5s. It's almost 100% reproducible. I mean it worked only once out of ~30 tries.
Ok, so it did work once? You saw some blue dots rotating around one time? Anyway, very encouraging to me. Sounds like my code is not to blame after all... but which code is to blame. Also interesting that the common factor seems to be the core 2 duo. Do you have new-ish GeForce drivers? I haven't updated the drivers on this machine where it works for a good long while. And it sounds like your card is similar era. --bb --bb
Jan 18 2009
parent Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 19 Jan 2009 10:20:51 +0900, Bill Baxter wrote:

 On Mon, Jan 19, 2009 at 8:53 AM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Mon, 19 Jan 2009 07:17:16 +0900, Bill Baxter wrote:

 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:

 """
 dwt.DWTException.DWTException: Failed to execute runnable

 object.Exception: Access Violation
 """

 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
Yes I can. From the first try. I've got an XP Home laptop, core 2 duo at 1.83GHz, 1GB RAM, GeForce Go 7600. DWT is trunk r119. Derelict is trunk r308. The executable is 2MB, built in about 6.5s. It's almost 100% reproducible. I mean it worked only once out of ~30 tries.
Ok, so it did work once? You saw some blue dots rotating around one time?
Yes. I see them every time before they crash, but once they kept rotating until I closed the app.
 Anyway, very encouraging to me.  Sounds like my code is not to blame
 after all... but which code is to blame.
Cannot see how you came to this conclusion. ;D
 Also interesting that the common factor seems to be the core 2 duo.
 Do you have new-ish GeForce drivers?  I haven't updated the drivers on
 this machine where it works for a good long while.  And it sounds like
 your card is similar era.
I've got 177.66 drivers downloaded from NVidia and hacked to work with my Samsung laptop. These are pretty recent.
 Another question for you Sergey, do you have VSync turned off by any chance?
 If this is some kind of multi-threading race situation, then not
 having VSync on could maybe be increasing the frequency with which the
 threads stomp on each other.
Yes I had it turned off. I tried to play with this setting and noticed that, although with VSync ON the dots rotate much slower, they always rotate approx. to the same *degree* before the crash.
 Also note that to get the crash to happen it seemed to be necessary to
 add both the menu and the CTabFolder to that example.
 Additionally I just noticed that if I click and hold on the tab's
 text, the gl updates pause for about a second but then resume.  This
 is coincidentally about as long as the program seems to run before it
 crashes for me (when it does crash).  So maybe there's some kind of
 background thread being used by that CTabItem.
I've removed both menu and tab like this: | public static void main() | { | Display display = new Display(); | Shell shell = new Shell(display); | // auto menubar = new Menu (shell, DWT.BAR); | // shell.setMenuBar(menubar); | // shell.setText("OpenGL in DWT"); | // shell.setLayout(new FillLayout()); | | // auto tabs = new CTabFolder(shell, DWT.BORDER); | // auto titem = new CTabItem(tabs, DWT.CLOSE); | | GLData data = new GLData(); | data.doubleBuffer = true; | data.alphaSize = 8; // want an alpha channel for readback of framebuffer w/ mask. | final GLCanvas canvas = new GLCanvas(shell, DWT.NO_BACKGROUND, data); | | // titem.setText("Canvas"); | // titem.setControl(canvas); | | canvas.addControlListener(new class ControlAdapter { The crash happens nevertheless, although now I cannot see the dots.
Jan 19 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jan 19, 2009 at 8:53 AM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Mon, 19 Jan 2009 07:17:16 +0900, Bill Baxter wrote:

 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:

 """
 dwt.DWTException.DWTException: Failed to execute runnable

 object.Exception: Access Violation
 """

 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
Yes I can. From the first try. I've got an XP Home laptop, core 2 duo at 1.83GHz, 1GB RAM, GeForce Go 7600. DWT is trunk r119. Derelict is trunk r308. The executable is 2MB, built in about 6.5s. It's almost 100% reproducible. I mean it worked only once out of ~30 tries.
Another question for you Sergey, do you have VSync turned off by any chance? If this is some kind of multi-threading race situation, then not having VSync on could maybe be increasing the frequency with which the threads stomp on each other. Also note that to get the crash to happen it seemed to be necessary to add both the menu and the CTabFolder to that example. Additionally I just noticed that if I click and hold on the tab's text, the gl updates pause for about a second but then resume. This is coincidentally about as long as the program seems to run before it crashes for me (when it does crash). So maybe there's some kind of background thread being used by that CTabItem. --bb
Jan 18 2009
prev sibling next sibling parent reply Sergey Kovrov <kovrov+digitalmars gmail.com> writes:
On 1/19/2009 12:17 AM, Bill Baxter wrote:
 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:

 """
 dwt.DWTException.DWTException: Failed to execute runnable

 object.Exception: Access Violation
 """

 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
I see nothing wrong with OpenGL part of the code. Have you tried to run it under ddbg? Stack trace might help in identifying issue. Off topic - I wonder why executable could be so big? (Forgive my ignorance I am not either Tango/DWT/Derelict user) -- serg.
Jan 18 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jan 19, 2009 at 8:58 AM, Sergey Kovrov
<kovrov+digitalmars gmail.com> wrote:
 On 1/19/2009 12:17 AM, Bill Baxter wrote:
 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:

 """
 dwt.DWTException.DWTException: Failed to execute runnable

 object.Exception: Access Violation
 """

 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
I see nothing wrong with OpenGL part of the code. Have you tried to run it under ddbg? Stack trace might help in identifying issue.
Stack trace ends in nvoglnt.dll. That's why I said the crash appears to be in the GL driver. I just tried it on my XP system here at work and it doesn't crash. In my other program I tended to see the crash happen on the call to swapBuffers, or on the first GL call after the swapBuffers. My guess would be it's happening the same place in this program. The crashing system is DELL XPS M1330 laptop w/ GeForce 8400M GS, Intel Core Duo and Vista Non-crashing system is DELL precision workstation w/ GeForce 7800 GTX, Dual Intel Xeons, and XP
 Off topic - I wonder why executable could be so big? (Forgive my ignorance I
 am not either Tango/DWT/Derelict user)
I dunno, but it's a frequent complaint. Maybe the linker just isn't very good at throwing away unneeded code? --bb
Jan 18 2009
prev sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Jan 18, 2009 at 7:41 PM, Bill Baxter <wbaxter gmail.com> wrote:
 Off topic - I wonder why executable could be so big? (Forgive my ignorance I
 am not either Tango/DWT/Derelict user)
I dunno, but it's a frequent complaint. Maybe the linker just isn't very good at throwing away unneeded code?
It isn't, from what I understand. Also, anything declared as a "const" is never thrown away and takes up space in the executable. Also struct and class inits, and typeinfo. It adds up.
Jan 18 2009
parent John Reimer <terminal.node gmail.com> writes:
Hello Jarrett,

 On Sun, Jan 18, 2009 at 7:41 PM, Bill Baxter <wbaxter gmail.com>
 wrote:
 
 Off topic - I wonder why executable could be so big? (Forgive my
 ignorance I am not either Tango/DWT/Derelict user)
 
I dunno, but it's a frequent complaint. Maybe the linker just isn't very good at throwing away unneeded code?
It isn't, from what I understand. Also, anything declared as a "const" is never thrown away and takes up space in the executable. Also struct and class inits, and typeinfo. It adds up.
Yes, Dwt has a long list of 'const' declarations in it. Feeling this was a serious concern, I once endeavored to convert as many as possible to enum (but never completed the task). Anyway, even with many many const's taking up space, it doesn't appear to account for the large binary size of an executable. If there were several thousand 'const' declarations, how would that account for more than a 10+ KB of storage? I wasn't able to justify that at least by my own understanding. What has been discussed before is the number of modules that get imported. There is a a near 1 to 1 ratio for class per modules, and dwt has so many classes; I think this adds an extraordinary amount of module typeinfo to the linker, some of which may be redundant or just sitting around taking up space. Furthermore, dwt does not attempt loose coupling of classes by any stretch of the imagination. So most modules need a reference from another module for significant or insignificant reasons. This means a typical application pulls in most of the modules in the whole dwt tree. I don't know the nitty gritty details of the problem, but I've heard that a re-engineered linker might do the trick. For one thing, we do need a simple way to implement a dynamic library version of it. A ddl version was demonstrated as feasible, but it really was not as simple as I'd like for the end-user. I was thinkng of another possible solution that would mean a slight refactoring of the public classes such that they would be converted to interfaces and then linked to a dynamic library containing the original classes. But the task might be too significant a change to dwt to warrant the fix. I'm still thinking it over, though. -JJR
Jan 18 2009
prev sibling parent Eldar Insafutdinov <e.insafutdinov nowhere.com> writes:
Bill Baxter Wrote:

 Here's a modified version of one of the DWT opengl snippets that
 reproduces the crash for me.
 About 1 in 10-15 runs this will crash (seems to be inside the GL
 driver) soon after startup with the error:
 
 """
 dwt.DWTException.DWTException: Failed to execute runnable
 
 object.Exception: Access Violation
 """
 
 Can anyone else reproduce this (particularly Vista users)?
 I'd be happy to send the exe to anyone who would like to try it off
 list.  But it's a 3MB exe  (compresses to about .7 MB).
 
 On Sun, Jan 18, 2009 at 11:35 PM, Sergey Kovrov
 <kovrov+digitalmars gmail.com> wrote:
 On 1/18/2009 5:51 AM, Bill Baxter wrote:
 So far haven't been able to isolate it.
 I updated another program that displays meshes with similar code and
 it works fine.
 So sounds like some kind of memory problem in my code to me too.  Or
 possibly passing a bad pointer to GL somewhere.  I have glGetError's
 sprinkled all over my code and get no errors from that.  But GL
 doesn't know if you pass it a bad pointer.

 I remember one problem I had long ago when I called glGetIntegerv for
 something, thinking it returned 1 value when it actually returned two.
  Seems likely it could be something similar here.
That was the primary reason for me to stop using GTK and start working on the Qt binding. I experienced not crashes but serious slowdowns with GTK and openGL. With Qt it doesn't happen.
Jan 18 2009