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

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

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.

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

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
next sibling parent 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).

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.

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.

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

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 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 next sibling parent 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
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
prev sibling next sibling parent 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
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
--0016361e894c375ab40460c92bed
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

--0016361e894c375ab40460c92bed Content-Type: application/octet-stream; name="Snippet174.d" Content-Disposition: attachment; filename="Snippet174.d" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fq49mh9n0 LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioKICogQ29weXJpZ2h0IChjKSAyMDAwLCAyMDA1IElCTSBD b3Jwb3JhdGlvbiBhbmQgb3RoZXJzLgogKiBBbGwgcmlnaHRzIHJlc2VydmVkLiBUaGlzIHByb2dy YW0gYW5kIHRoZSBhY2NvbXBhbnlpbmcgbWF0ZXJpYWxzCiAqIGFyZSBtYWRlIGF2YWlsYWJsZSB1 bmRlciB0aGUgdGVybXMgb2YgdGhlIEVjbGlwc2UgUHVibGljIExpY2Vuc2UgdjEuMAogKiB3aGlj aCBhY2NvbXBhbmllcyB0aGlzIGRpc3RyaWJ1dGlvbiwgYW5kIGlzIGF2YWlsYWJsZSBhdAogKiBo dHRwOi8vd3d3LmVjbGlwc2Uub3JnL2xlZ2FsL2VwbC12MTAuaHRtbAogKgogKiBDb250cmlidXRv cnM6CiAqICAgICBTZWJhc3RpYW4gRGF2aWRzIC0gaW5pdGlhbCBpbXBsZW1lbnRhdGlvbgogKiAg ICAgSUJNIENvcnBvcmF0aW9uCiAqIFBvcnQgdG8gdGhlIEQgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2U6 CiAqICAgICBCaWxsIEJheHRlciA8YmlsbEBiaWxsYmF4dGVyLmNvbT4KICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKiovCm1vZHVsZSBvcGVuZ2wuU25pcHBldDE3NDsKCi8qCiAqIFNXVCBPcGVuR0wgc25p cHBldDogZHJhdyBhIHNxdWFyZQogKiAKICogVGhpcyBzbmlwcGV0IHJlcXVpcmVzIHRoZSBleHBl cmltZW50YWwgb3JnLmVjbGlwc2Uuc3d0Lm9wZW5nbCBwbHVnaW4sIHdoaWNoCiAqIGlzIG5vdCBp bmNsdWRlZCBpbiBTV1QgYnkgZGVmYXVsdCBhbmQgc2hvdWxkIG9ubHkgYmUgdXNlZCB3aXRoIHZl cnNpb25zIG9mCiAqIFNXVCBwcmlvciB0byAzLjIuICBGb3IgaW5mb3JtYXRpb24gb24gdXNpbmcg T3BlbkdMIGluIFNXVCBzZWUKICogaHR0cDovL3d3dy5lY2xpcHNlLm9yZy9zd3Qvb3BlbmdsLyAu CiAqIAogKiBGb3IgYSBsaXN0IG9mIGFsbCBTV1QgZXhhbXBsZSBzbmlwcGV0cyBzZWUKICogaHR0 cDovL3d3dy5lY2xpcHNlLm9yZy9zd3Qvc25pcHBldHMvCiAqIAogKiBAc2luY2UgMy4yCiAqLwpp bXBvcnQgZHd0LkRXVDsKaW1wb3J0IGR3dC5kd3RoZWxwZXIuUnVubmFibGU7CmltcG9ydCBkd3Qu d2lkZ2V0cy5EaXNwbGF5OwppbXBvcnQgZHd0LndpZGdldHMuU2hlbGw7CmltcG9ydCBkd3QuZ3Jh cGhpY3MuUmVjdGFuZ2xlOwppbXBvcnQgZHd0LmV2ZW50cy5Db250cm9sRXZlbnQ7CmltcG9ydCBk d3QuZXZlbnRzLkNvbnRyb2xBZGFwdGVyOwppbXBvcnQgZHd0LmxheW91dC5GaWxsTGF5b3V0Owpp bXBvcnQgZHd0Lm9wZW5nbC5HTENhbnZhczsKaW1wb3J0IGR3dC5vcGVuZ2wuR0xEYXRhOwppbXBv cnQgZHd0LndpZGdldHMuTWVudTsKaW1wb3J0IGR3dC5jdXN0b20uQ1RhYkZvbGRlcjsKaW1wb3J0 IGR3dC5jdXN0b20uQ1RhYkl0ZW07CgppbXBvcnQgZGVyZWxpY3Qub3BlbmdsLmdsOwppbXBvcnQg ZGVyZWxpY3Qub3BlbmdsLmdsdTsKCmltcG9ydCBNYXRoID0gdGFuZ28ubWF0aC5NYXRoOwoKc3Rh dGljIHRoaXMoKQp7CiAgICBEZXJlbGljdEdMLmxvYWQoKTsKICAgIERlcmVsaWN0R0xVLmxvYWQo KTsKCn0KCnB1YmxpYyBzdGF0aWMgdm9pZCBtYWluKCkgCnsKICAgIERpc3BsYXkgZGlzcGxheSA9 IG5ldyBEaXNwbGF5KCk7CiAgICBTaGVsbCBzaGVsbCA9IG5ldyBTaGVsbChkaXNwbGF5KTsKICAg IGF1dG8gbWVudWJhciA9IG5ldyBNZW51IChzaGVsbCwgRFdULkJBUik7CiAgICBzaGVsbC5zZXRN ZW51QmFyKG1lbnViYXIpOwogICAgc2hlbGwuc2V0VGV4dCgiT3BlbkdMIGluIERXVCIpOwogICAg c2hlbGwuc2V0TGF5b3V0KG5ldyBGaWxsTGF5b3V0KCkpOwoKICAgIGF1dG8gdGFicyA9IG5ldyBD VGFiRm9sZGVyKHNoZWxsLCBEV1QuQk9SREVSKTsKICAgIGF1dG8gdGl0ZW0gPSBuZXcgQ1RhYkl0 ZW0odGFicywgRFdULkNMT1NFKTsKCiAgICBHTERhdGEgZGF0YSA9IG5ldyBHTERhdGEoKTsKICAg IGRhdGEuZG91YmxlQnVmZmVyID0gdHJ1ZTsKICAgIGRhdGEuYWxwaGFTaXplID0gODsgLy8gd2Fu dCBhbiBhbHBoYSBjaGFubmVsIGZvciByZWFkYmFjayBvZiBmcmFtZWJ1ZmZlciB3LyBtYXNrLgog ICAgZmluYWwgR0xDYW52YXMgY2FudmFzID0gbmV3IEdMQ2FudmFzKHRhYnMsIERXVC5OT19CQUNL R1JPVU5ELCBkYXRhKTsKCiAgICB0aXRlbS5zZXRUZXh0KCJDYW52YXMiKTsKICAgIHRpdGVtLnNl dENvbnRyb2woY2FudmFzKTsKCiAgICBjYW52YXMuYWRkQ29udHJvbExpc3RlbmVyKG5ldyBjbGFz cyBDb250cm9sQWRhcHRlciB7CiAgICAgICAgcHVibGljIHZvaWQgY29udHJvbFJlc2l6ZWQoQ29u dHJvbEV2ZW50IGUpIHsKICAgICAgICAgICAgcmVzaXplKGNhbnZhcyk7CiAgICAgICAgfQogICAg fSk7CiAgICBzaGVsbC5vcGVuKCk7CiAgICBpbml0KGNhbnZhcyk7CiAgICBhdXRvIHggPSAobmV3 IGNsYXNzIFJ1bm5hYmxlIHsKICAgICAgICBwdWJsaWMgdm9pZCBydW4oKSB7CiAgICAgICAgICAg IGlmIChjYW52YXMuaXNEaXNwb3NlZCgpKSByZXR1cm47CiAgICAgICAgICAgIHJlbmRlcigpOwog ICAgICAgICAgICBjYW52YXMuc3dhcEJ1ZmZlcnMoKTsKICAgICAgICAgICAgLy9jYW52YXMuZ2V0 RGlzcGxheSgpLnRpbWVyRXhlYygxNSwgdGhpcyk7CiAgICAgICAgICAgIGNhbnZhcy5nZXREaXNw bGF5KCkuYXN5bmNFeGVjKHRoaXMpOwogICAgICAgIH0KICAgIH0pOy8vLnJ1bigpOwogICAgZGlz cGxheS5hc3luY0V4ZWMoeCk7CiAgICB3aGlsZSAoIXNoZWxsLmlzRGlzcG9zZWQoKSkgewogICAg ICAgIGlmICghZGlzcGxheS5yZWFkQW5kRGlzcGF0Y2goKSkgZGlzcGxheS5zbGVlcCgpOwogICAg fQogICAgZGlzcGxheS5kaXNwb3NlKCk7Cn0KCnN0YXRpYyB2b2lkIGluaXQoR0xDYW52YXMgY2Fu dmFzKSB7CiAgICBjYW52YXMuc2V0Q3VycmVudCgpOwogICAgcmVzaXplKGNhbnZhcyk7CiAgICBn bENsZWFyQ29sb3IoMS4wZiwgMS4wZiwgMS4wZiwgMC4wZik7CiAgICBnbENvbG9yM2YoMC4wZiwg MC4wZiwgMC4wZik7CiAgICBnbENsZWFyRGVwdGgoMS4wZik7CiAgICBnbEVuYWJsZShHTF9ERVBU SF9URVNUKTsKICAgIGdsSGludChHTF9QRVJTUEVDVElWRV9DT1JSRUNUSU9OX0hJTlQsIEdMX05J Q0VTVCk7Cn0KCmZsb2F0W10gVkVSVFMgPSBbCiAgICA2OTAuOTUzODU3NDIxOWYsIDM3Ny42NDc1 NTI0OTAyLCAwLjAwMDAwMDAwMDAsCiAgICA2NjEuMzcyMjUzNDE4MCwgMzc4LjM3NDE3NjAyNTQs IDAuMDAwMDAwMDAwMCwKICAgIDY1Mi4wNzExNjY5OTIyLCAzNzcuNjQ0MDczNDg2MywgMC4wMDAw MDAwMDAwLAogICAgNjE2LjQxNTQwNTI3MzQsIDM3OC42OTU3NzAyNjM3LCAwLjAwMDAwMDAwMDAs CiAgICA2MDEuMDQ2OTM2MDM1MiwgMzc4LjE0NzcwNTA3ODEsIDAuMDAwMDAwMDAwMCwKICAgIDUx OS44NDUyNzU4Nzg5LCAzNzkuNjAzMzYzMDM3MSwgMC4wMDAwMDAwMDAwLAogICAgNTEwLjU0MDMx MzcyMDcsIDM3OC44ODg2MTA4Mzk4LCAwLjAwMDAwMDAwMDAsCiAgICAzMDYuMjk4NjE0NTAyMCwg Mzg1LjEwMzM5MzU1NDcsIDAuMDAwMDAwMDAwMCwKICAgIDMwMS4xNDcyMTY3OTY5LCAzODYuMjYw NDY3NTI5MywgMC4wMDAwMDAwMDAwLAogICAgMTYxLjIzOTcwMDMxNzQsIDM5MC4zNTcwNTU2NjQx LCAwLjAwMDAwMDAwMDAsCiAgICAxMzMuOTcwMTIzMjkxMCwgMzg5LjE0NjQyMzMzOTgsIDAuMDAw MDAwMDAwMCwKICAgIDEyOC42ODk0OTg5MDE0LCAzODcuMjkzMzA0NDQzNCwgMC4wMDAwMDAwMDAw LAogICAgMTEyLjM2NDQxMDQwMDQsIDM4NS43NTc0MTU3NzE1LCAwLjAwMDAwMDAwMDAsCiAgICA3 OS4wNTUwMjMxOTM0LCAzODYuNzA5MDc1OTI3NywgMC4wMDAwMDAwMDAwLAogICAgNjcuODc3NTMy OTU5MCwgMzg1LjAyNjI3NTYzNDgsIDAuMDAwMDAwMDAwMCwKICAgIDYxLjc1NTUxNjA1MjIsIDM4 My4xOTk3OTg1ODQwLCAwLjAwMDAwMDAwMDAsCiAgICA1Ni41OTkyMjQwOTA2LCAzNzkuMzQ1NTUw NTM3MSwgMC4wMDAwMDAwMDAwLAogICAgNTEuMzcxMzY4NDA4MiwgMzcyLjQ5MjczNjgxNjQsIDAu MDAwMDAwMDAwMCwKICAgIDQ4LjU0NDA3ODgyNjksIDM2Ni42MjYwMzc1OTc3LCAwLjAwMDAwMDAw MDAsCiAgICA1MS4zMzE1NTgyMjc1LCAzNTUuMTEyNjQwMzgwOSwgMC4wMDAwMDAwMDAwLAogICAg NTYuNzQ1OTg2OTM4NSwgMzUwLjMyOTYyMDM2MTMsIDAuMDAwMDAwMDAwMCwKICAgIDYyLjcwMDQz OTQ1MzEsIDM0Ny4xNTg0NDcyNjU2LCAwLjAwMDAwMDAwMDAsCiAgICA5NS44OTA0MDM3NDc2LCAz NDYuMjA1NDQ0MzM1OSwgMC4wMDAwMDAwMDAwLAogICAgMTAzLjA3NDEwNDMwOTEsIDM0OC4wMDM0 MTc5Njg3LCAwLjAwMDAwMDAwMDAsCiAgICAxNDYuOTIxOTY2NTUyNywgMzUwLjc1ODE0ODE5MzQs IDAuMDAwMDAwMDAwMCwKICAgIDE2Ny4xMzU1NTkwODIwLCAzNTIuMTY1NzcxNDg0NCwgMC4wMDAw MDAwMDAwLAogICAgMTc1LjM4NjI0NTcyNzUsIDM1Mi45MzQ0Nzg3NTk4LCAwLjAwMDAwMDAwMDAs CiAgICAyMDAuNTk2MDY5MzM1OSwgMzUyLjE4OTc1ODMwMDgsIDAuMDAwMDAwMDAwMCwKICAgIDIw NS44MDUxMzAwMDQ5LCAzNTMuMDQ3NzYwMDA5OCwgMC4wMDAwMDAwMDAwLAogICAgMzA1LjIwNzg1 NTIyNDYsIDM1MC4xMjE2NDMwNjY0LCAwLjAwMDAwMDAwMDAsCiAgICAzMTIuMzM3NjE1OTY2OCwg MzUwLjkwOTg4MTU5MTgsIDAuMDAwMDAwMDAwMCwKICAgIDM0My43MjY1MzE5ODI0LCAzNDkuOTY4 MTM5NjQ4NCwgMC4wMDAwMDAwMDAwLAogICAgMzkyLjU2OTMwNTQxOTksIDM1MC40OTk4NDc0MTIx LCAwLjAwMDAwMDAwMDAsCiAgICAzOTkuNzMyOTcxMTkxNCwgMzUxLjI4MzY5MTQwNjMsIDAuMDAw MDAwMDAwMCwKICAgIDQ4MC4wODUxMTM1MjU0LCAzNDguODA2Mzk2NDg0NCwgMC4wMDAwMDAwMDAw LAogICAgNDg4LjI2NDUyNjM2NzIsIDM0OS41NTcwNjc4NzExLCAwLjAwMDAwMDAwMDAsCiAgICA0 OTMuNDM1MzYzNzY5NSwgMzUwLjQwNDgxNTY3MzgsIDAuMDAwMDAwMDAwMCwKICAgIDUzNC4xNTA3 NTY4MzU5LCAzNDkuMTU0Mjk2ODc1MCwgMC4wMDAwMDAwMDAwLAogICAgNjMwLjkyOTg3MDYwNTUs IDM1MS4yMjA5NDcyNjU2LCAwLjAwMDAwMDAwMDAsCiAgICA2NjAuNDY5MDU1MTc1OCwgMzUyLjM0 ODIzNjA4NDAsIDAuMDAwMDAwMDAwMCwKICAgIDY3NC44Mjg0MzAxNzU4LCAzNTMuOTYzMzc4OTA2 MiwgMC4wMDAwMDAwMDAwLAogICAgNzA0LjQzOTMzMTA1NDcsIDM1Mi44MTcwNDcxMTkxLCAwLjAw MDAwMDAwMDAsCiAgICA3MTguNzcxNjY3NDgwNSwgMzU2LjQyMjQ4NTM1MTYsIDAuMDAwMDAwMDAw MCwKICAgIDcyOS4zMzAyNjEyMzA1LCAzNjIuNzcxNTQ1NDEwMiwgMC4wMDAwMDAwMDAwLAogICAg NzM2Ljg3MTMzNzg5MDYsIDM3MS45MTgwNjAzMDI3LCAwLjAwMDAwMDAwMDAsCiAgICA3MzYuMzI0 MzQwODIwMywgMzc3LjE0OTA3ODM2OTEsIDAuMDAwMDAwMDAwMCwKICAgIDczMS40MTg5NDUzMTI1 LCAzODAuMjk5MTMzMzAwOCwgMC4wMDAwMDAwMDAwLAogICAgNzIxLjU3NjU5OTEyMTEsIDM4NC42 MDA2MTY0NTUxLCAwLjAwMDAwMDAwMDAsCiAgICA3MDguNTgwMjYxMjMwNSwgMzg0Ljk5NDExMDEw NzQsIDAuMDAwMDAwMDAwMCwKICAgIDcwMy40MDU1Nzg2MTMzLCAzODQuMjg3OTYzODY3MiwgMC4w MDAwMDAwMDAwLAogICAgNDA4LjMzNzM0MTMwODYsIDM4Mi4wMzE0NjM2MjMwLCAwLjAwMDAwMDAw MDAsCiAgICAyMzEuMjg5NjcyODUxNiwgMzg4LjMxOTU4MDA3ODEsIDAuMDAwMDAwMDAwMCwKICAg IDEzNi4zNDk3MDA5Mjc3LCAzNzQuNjAwNDMzMzQ5NiwgMC4wMDAwMDAwMDAwLAogICAgMzAwLjYy NTI0NDE0MDYsIDM3Mi4yOTgzMzk4NDM3LCAwLjAwMDAwMDAwMDAsCiAgICA0NTkuNTM5NzAzMzY5 MSwgMzgwLjQ1OTkzMDQxOTksIDAuMDAwMDAwMDAwMCwKICAgIDcwOC4wMDAxMjIwNzAzLCAzNzEu MDAwMDMwNTE3NiwgMC4wMDAwMDAwMDAwLAogICAgNjguMDgxNjY1MDM5MSwgMzY0LjY2MzIwODAw NzgsIDAuMDAwMDAwMDAwMCwKICAgIDY3LjU2OTIzNjc1NTQsIDM3NC44MzQyNTkwMzMyLCAwLjAw MDAwMDAwMDAsCiAgICA1OC4zNjc5NDY2MjQ4LCAzNjUuNTExMzgzMDU2NiwgMC4wMDAwMDAwMDAw LAogICAgOTQuNjQ1OTY1NTc2MiwgMzY2LjExMDEzNzkzOTUsIDAuMDAwMDAwMDAwMCwKICAgIDM1 Ny4yOTgyMTc3NzM0LCAzODMuNTgxMTE1NzIyNywgMC4wMDAwMDAwMDAwLAogICAgMzA3LjQzOTIw ODk4NDQsIDM2Mi4xMjE5Nzg3NTk4LCAwLjAwMDAwMDAwMDAsCiAgICAxNjkuNDE5NDc5MzcwMSwg MzcyLjA0ODAwNDE1MDQsIDAuMDAwMDAwMDAwMCwKICAgIDUyNC4xNjM0NTIxNDg0LCAzNTUuNzQz OTI3MDAyMCwgMC4wMDAwMDAwMDAwLAogICAgNjU3Ljc0MTQ1NTA3ODEsIDM2NS40NTQ1ODk4NDM3 LCAwLjAwMDAwMDAwMDAsCiAgICA4MS4xMzQ0NDUxOTA0LCAzNzAuNjg0NjYxODY1MiwgMC4wMDAw MDAwMDAwLAogICAgNzE5LjAzNjAxMDc0MjIsIDM2Ny45NTI4ODA4NTk0LCAwLjAwMDAwMDAwMDAs CiAgICAzMjguMDEwODAzMjIyNywgMzUwLjQzNjA5NjE5MTQsIDAuMDAwMDAwMDAwMCwKICAgIDY0 NS42NzE2OTE4OTQ1LCAzNTEuNzgzMDgxMDU0NywgMC4wMDAwMDAwMDAwLAogICAgNjc2LjE2MTQ5 OTAyMzQsIDM3OC4wMTA5MjUyOTMwLCAwLjAwMDAwMDAwMDAsCiAgICA2NjYuNTIzMjU0Mzk0NSwg MzYwLjQwMjE2MDY0NDUsIDAuMDAwMDAwMDAwMCwKICAgIDYzNC4yNjUwNzU2ODM2LCAzNzguMTY5 ODYwODM5OCwgMC4wMDAwMDAwMDAwLAogICAgNTgyLjM1NDk4MDQ2ODcsIDM1MC4xNzQwNDE3NDgw LCAwLjAwMDAwMDAwMDAsCiAgICAxOTYuMjQyMTcyMjQxMiwgMzg5LjM0MTE1NjAwNTksIDAuMDAw MDAwMDAwMCwKICAgIDEyMS42ODc2MzczMjkxLCAzNzQuNjM1NDM3MDExNywgMC4wMDAwMDAwMDAw LAogICAgMTQ3LjgzOTIzMzM5ODQsIDM4My45OTg5OTI5MTk5LCAwLjAwMDAwMDAwMDAsCiAgICAx MDcuNDcxNjk0OTQ2MywgMzcyLjQ1MzMzODYyMzAsIDAuMDAwMDAwMDAwMCwKICAgIDcwOS45NzY0 NDA0Mjk3LCAzNjEuMjE5ODc5MTUwNCwgMC4wMDAwMDAwMDAwLAogICAgNTA2Ljk2NTc4OTc5NDks IDM2OS4yNTM3NTM2NjIxLCAwLjAwMDAwMDAwMDAsCiAgICA4Ny4wNzAyOTcyNDEyLCAzNTIuNjkx NzExNDI1OCwgMC4wMDAwMDAwMDAwLAogICAgOTUuNjg4NzM1OTYxOSwgMzg2LjIzMzQyODk1NTEs IDAuMDAwMDAwMDAwMCwKICAgIDc2LjA5NTY5NTQ5NTYsIDM3OC4xNTI4MzIwMzEyLCAwLjAwMDAw MDAwMDAsCiAgICA2NzcuNjgxNzAxNjYwMiwgMzY1Ljg4MDY3NjI2OTUsIDAuMDAwMDAwMDAwMCwK ICAgIDY4OS42Njk2Nzc3MzQ0LCAzNTMuMzkxMTEzMjgxMiwgMC4wMDAwMDAwMDAwLAogICAgNjk4 LjQ2MjI4MDI3MzQsIDM3MS45NTAwMTIyMDcwLCAwLjAwMDAwMDAwMDAsCiAgICAzODIuNjgwODQ3 MTY4MCwgMzgyLjgxNDYwNTcxMjksIDAuMDAwMDAwMDAwMCwKICAgIDYzOC4wNjAxODA2NjQxLCAz NTcuNzczOTU2Mjk4OCwgMC4wMDAwMDAwMDAwLAogICAgNjA2LjY3NzY3MzMzOTgsIDM1MC42OTY3 NzczNDM4LCAwLjAwMDAwMDAwMDAsCiAgICA2NDkuOTY2Nzk2ODc1MCwgMzYwLjA4MTY5NTU1NjYs IDAuMDAwMDAwMDAwMCwKICAgIDIwMC45MjEyMDM2MTMzLCAzNjYuMTYzODQ4ODc3MCwgMC4wMDAw MDAwMDAwLAogICAgMTI0Ljk4NDUzNTIxNzMsIDM0OS4zODIwODAwNzgxLCAwLjAwMDAwMDAwMDAs CiAgICAxNTIuMjUzNDMzMjI3NSwgMzY3LjI0OTM1OTEzMDksIDAuMDAwMDAwMDAwMCwKICAgIDI2 Ni4yMDg4MDEyNjk1LCAzODcuMjkwMTMwNjE1MiwgMC4wMDAwMDAwMDAwLAogICAgNTEzLjg2NjQ1 NTA3ODEsIDM0OS43ODAzMzQ0NzI3LCAwLjAwMDAwMDAwMDAsCiAgICA0ODUuMTQwNDExMzc3MCwg Mzc5LjY3MDE2NjAxNTYsIDAuMDAwMDAwMDAwMCwKICAgIDg1LjgwODI5NjIwMzYsIDM2Mi4zOTc1 NTI0OTAyLCAwLjAwMDAwMDAwMDAsCiAgICA2NjguMjk3NDI0MzE2NCwgMzcwLjU5NzY4Njc2NzYs IDAuMDAwMDAwMDAwMCwKICAgIDE3OC43Mjk3ODIxMDQ1LCAzODkuODUwNTU1NDE5OSwgMC4wMDAw MDAwMDAwLAogICAgNjQyLjAzNDYwNjkzMzYsIDM2OS4wMTM1ODAzMjIzLCAwLjAwMDAwMDAwMDAs CiAgICAxNzcuNzMxNzk2MjY0NiwgMzY0LjEwMjQ3ODAyNzMsIDAuMDAwMDAwMDAwMCwKICAgIDE4 OC4yMzUzOTczMzg5LCAzNTkuMzczNjI2NzA5MCwgMC4wMDAwMDAwMDAwLAogICAgMTU4LjgyNTMw MjEyNDAsIDM3OC4zNzg1NzA1NTY2LCAwLjAwMDAwMDAwMDAsCiAgICAxMDUuNjcyMzAyMjQ2MSwg MzYwLjE2MDMwODgzNzksIDAuMDAwMDAwMDAwMCwKICAgIDk2LjMwMzkwMTY3MjQsIDM1Ni4yMjU0 MzMzNDk2LCAwLjAwMDAwMDAwMDAsCiAgICAxMTQuMDEzNzcxMDU3MSwgMzQ4LjY5MjYyNjk1MzEs IDAuMDAwMDAwMDAwMCwKICAgIDE0Ni4wNzE3MTYzMDg2LCAzNzQuNjAzMTc5OTMxNiwgMC4wMDAw MDAwMDAwLAogICAgMjU1LjQ5NDk5NTExNzIsIDM1MS41ODg3MTQ1OTk2LCAwLjAwMDAwMDAwMDAs CiAgICA0ODguNTMxOTIxMzg2NywgMzYzLjUyNTQ1MTY2MDIsIDAuMDAwMDAwMDAwMCwKICAgIDkw LjcxODk0MDczNDksIDM3Ni4zODQwMzMyMDMxLCAwLjAwMDAwMDAwMDAsCiAgICAxMDMuODUyMjAz MzY5MSwgMzgxLjI2Nzg4MzMwMDgsIDAuMDAwMDAwMDAwMCwKICAgIDY5Ny40ODA3NzM5MjU4LCAz NjEuMTUxOTQ3MDIxNSwgMC4wMDAwMDAwMDAwLAogICAgMzMxLjc3Mjk3OTczNjMsIDM4NC4zNDIy MjQxMjExLCAwLjAwMDAwMDAwMDAsCiAgICAzNjguMTMxNjUyODMyMCwgMzUwLjIzODk4MzE1NDMs IDAuMDAwMDAwMDAwMCwKICAgIDI4My43MDI4MTk4MjQyLCAzODYuNzc1MzYwMTA3NCwgMC4wMDAw MDAwMDAwLAogICAgNjI1LjI0MDY2MTYyMTEsIDM3NC43MDg2MTgxNjQxLCAwLjAwMDAwMDAwMDAs CiAgICAxMjguOTg1OTc3MTcyOSwgMzYyLjczMDA0MTUwMzksIDAuMDAwMDAwMDAwMCwKICAgIDQ5 Ny41ODEyMzc3OTMwLCAzNzMuODU1MTYzNTc0MiwgMC4wMDAwMDAwMDAwLAogICAgMzM2LjQwNTgy Mjc1MzksIDM2NS44MDY4MjM3MzA1LCAwLjAwMDAwMDAwMDAsCiAgICA2MTQuNjk2Nzc3MzQzNywg MzYzLjYzODMzNjE4MTYsIDAuMDAwMDAwMDAwMCwKICAgIDYzMS42NzM2NDUwMTk1LCAzNjYuMjMw MTk0MDkxOCwgMC4wMDAwMDAwMDAwLAogICAgMjkyLjI1MTQwMzgwODYsIDM3OS42NTQwNTI3MzQ0 LCAwLjAwMDAwMDAwMDAsCiAgICAxOTEuODgxMzAxODc5OSwgMzY3LjY0NTU2ODg0NzcsIDAuMDAw MDAwMDAwMCwKICAgIDExNy4wNTQ0MjgxMDA2LCAzNjMuNzgzMTcyNjA3NCwgMC4wMDAwMDAwMDAw LAogICAgMTM1Ljk2NTc0NDAxODYsIDM1MC4wNzA3NzAyNjM3LCAwLjAwMDAwMDAwMDAsCiAgICAx NDAuOTAzMjQ0MDE4NiwgMzYzLjc0MTUxNjExMzMsIDAuMDAwMDAwMDAwMCwKICAgIDMzNi4wNzgz NjkxNDA2LCAzNTYuMDgxOTA5MTc5NywgMC4wMDAwMDAwMDAwLAogICAgNjA4Ljk1MjQ1MzYxMzMs IDM3MS44OTc1ODMwMDc4LCAwLjAwMDAwMDAwMDAsCiAgICA1NjAuMzkxMjk2Mzg2NywgMzc4Ljg2 ODg5NjQ4NDQsIDAuMDAwMDAwMDAwMCwKICAgIDYxOC44MTIyNTU4NTk0LCAzNTAuOTU4ODAxMjY5 NSwgMC4wMDAwMDAwMDAwLAogICAgNjI0LjA4NTYzMjMyNDIsIDM1OS41NTc1ODY2Njk5LCAwLjAw MDAwMDAwMDAsCiAgICAyMzAuNzI4ODA1NTQyMCwgMzUyLjMyMzI3MjcwNTEsIDAuMDAwMDAwMDAw MCwKICAgIDYwNC44Nzk1MTY2MDE2LCAzNjAuNTg5OTY1ODIwMywgMC4wMDAwMDAwMDAwLAogICAg MjE4LjY4NDkwNjAwNTksIDM2NS4xMTIxMjE1ODIwLCAwLjAwMDAwMDAwMDAsCiAgICAyMDkuNTcx ODg0MTU1MywgMzYxLjgzNDUwMzE3MzgsIDAuMDAwMDAwMDAwMCwKICAgIDc5LjI4NzYyMDU0NDQs IDM0Ni42ODI3Njk3NzU0LCAwLjAwMDAwMDAwMDAsCiAgICA2Mi4xMDEzOTg0NjgwLCAzNTcuNDI3 ODg2OTYyOSwgMC4wMDAwMDAwMDAwLAogICAgMzU1LjM2NDM0OTM2NTIsIDM2NC44NDI4OTU1MDc4 LCAwLjAwMDAwMDAwMDAsCiAgICAzOTQuMjgwNDg3MDYwNSwgMzY3LjM3MjI4MzkzNTUsIDAuMDAw MDAwMDAwMCwKICAgIDE1Ni42NTQ2OTM2MDM1LCAzNTYuNzY1NTk0NDgyNCwgMC4wMDAwMDAwMDAw LAogICAgMTY1LjUxMDM2MDcxNzgsIDM2Mi40MDkxNDkxNjk5LCAwLjAwMDAwMDAwMDAsCiAgICA0 NDAuMDU3NDM0MDgyMCwgMzUwLjA1NjY0MDYyNTAsIDAuMDAwMDAwMDAwMCwKICAgIDY4OC41MTg0 OTM2NTIzLCAzNjcuMjQyMDY1NDI5NywgMC4wMDAwMDAwMDAwLAogICAgMTk5LjMwMTExNjk0MzQs IDM3Ny44OTUyNjM2NzE5LCAwLjAwMDAwMDAwMDAsCiAgICAyMTMuNzM0NDUxMjkzOSwgMzg4Ljgz MjEyMjgwMjcsIDAuMDAwMDAwMDAwMCwKICAgIDIwNC44ODIyMzI2NjYwLCAzODUuNDY5NzU3MDgw MSwgMC4wMDAwMDAwMDAwLAogICAgMjExLjM4NTk4NjMyODEsIDM3NS4wNTI2NzMzMzk4LCAwLjAw MDAwMDAwMDAsCiAgICAyMjQuNjU2ODYwMzUxNiwgMzc2Ljg3NDc1NTg1OTQsIDAuMDAwMDAwMDAw MCwKICAgIDIzMi4zNDM3ODA1MTc2LCAzNjUuNzA0MjIzNjMyOCwgMC4wMDAwMDAwMDAwLAogICAg MjIyLjUyOTkyMjQ4NTQsIDM4OC41NzU2MjI1NTg2LCAwLjAwMDAwMDAwMDAsCiAgICAyNDMuMjk4 MDE5NDA5MiwgMzU3LjYzMjgxMjUwMDAsIDAuMDAwMDAwMDAwMCwKICAgIDI1Ny40NTcxMjI4MDI3 LCAzNzAuNDQ1NzcwMjYzNywgMC4wMDAwMDAwMDAwLAogICAgMjUyLjg1MDIwNDQ2NzgsIDM2MS4z Nzc5NjAyMDUxLCAwLjAwMDAwMDAwMDAsCiAgICAyNDguNzIxMDIzNTU5NiwgMzg3LjgwNzA5ODM4 ODcsIDAuMDAwMDAwMDAwMCwKICAgIDI0NC4yOTA4MzI1MTk1LCAzNzEuMjg1ODU4MTU0MywgMC4w MDAwMDAwMDAwLAogICAgMjUxLjMyNDYzMDczNzMsIDM3OC4yNjQzNzM3NzkzLCAwLjAwMDAwMDAw MDAsCiAgICAyMzUuNzM1NTE5NDA5MiwgMzc4LjI2MjM5MDEzNjcsIDAuMDAwMDAwMDAwMCwKICAg IDE4Ni4zMDQwNjE4ODk2LCAzNzkuMzA5MjY1MTM2NywgMC4wMDAwMDAwMDAwLAogICAgMTc1Ljk1 MTc2Njk2NzgsIDM3OS45OTgzNTIwNTA4LCAwLjAwMDAwMDAwMDAsCiAgICAxNjcuMDMyNjIzMjkx MCwgMzgyLjk4MDQ2ODc1MDAsIDAuMDAwMDAwMDAwMCwKICAgIDMyMi4wMDQ2Mzg2NzE5LCAzNjMu NTIzODk1MjYzNywgMC4wMDAwMDAwMDAwLAogICAgMzIwLjI3NDEzOTQwNDMsIDM1NC44NjEyNjcw ODk4LCAwLjAwMDAwMDAwMDAsCiAgICAzMjcuNzQ0NjU5NDIzOCwgMzczLjUzNjc3MzY4MTYsIDAu MDAwMDAwMDAwMCwKICAgIDMxOS4wNDM2MDk2MTkxLCAzODQuNzIyNTAzNjYyMSwgMC4wMDAwMDAw MDAwLAogICAgMzEzLjQzNzY1MjU4NzksIDM3My4zMzMwMzgzMzAxLCAwLjAwMDAwMDAwMDAsCiAg ICAyODAuNDI4NDY2Nzk2OSwgMzUwLjg2MTMyODEyNTAsIDAuMDAwMDAwMDAwMCwKICAgIDI4Mi43 MTQzMjQ5NTEyLCAzNzcuMDY2MDQwMDM5MSwgMC4wMDAwMDAwMDAwLAogICAgMjkyLjg1MjYzMDYx NTIsIDM1MC40OTQyNjI2OTUzLCAwLjAwMDAwMDAwMDAsCiAgICAyOTAuMTQzMzEwNTQ2OSwgMzY5 LjAwNzI5MzcwMTIsIDAuMDAwMDAwMDAwMCwKICAgIDI3Ni43NDk2MzM3ODkxLCAzNjQuMzg3NDgx Njg5NSwgMC4wMDAwMDAwMDAwLAogICAgMjY3Ljk4MjY5NjUzMzIsIDM1MS4yMjYzNDg4NzcwLCAw LjAwMDAwMDAwMDAsCiAgICAyODYuOTEwMjQ3ODAyNywgMzU5LjEwNDAzNDQyMzgsIDAuMDAwMDAw MDAwMCwKICAgIDI3MC4wNDIzODg5MTYwLCAzNzUuMTk3NjAxMzE4NCwgMC4wMDAwMDAwMDAwLAog ICAgMjc0Ljg3MDM5MTg0NTcsIDM4My4yOTM5NzU4MzAxLCAwLjAwMDAwMDAwMDAsCiAgICAyNjUu Mzk4NjUxMTIzMCwgMzYyLjI3NjM2NzE4NzUsIDAuMDAwMDAwMDAwMCwKICAgIDU5NC41NDEyNTk3 NjU2LCAzNTAuNDM2Nzk4MDk1NywgMC4wMDAwMDAwMDAwLAogICAgNTgwLjcyMTYxODY1MjMsIDM3 OC41MDUzNzEwOTM4LCAwLjAwMDAwMDAwMDAsCiAgICA1OTUuMTIyNzQxNjk5MiwgMzU5Ljk2NzI1 NDYzODcsIDAuMDAwMDAwMDAwMCwKICAgIDIxOC4yMzUxODM3MTU4LCAzNTIuNjgzMzQ5NjA5NCwg MC4wMDAwMDAwMDAwLAogICAgNzYuMTYzNDgyNjY2MCwgMzU3LjEyMjEzMTM0NzcsIDAuMDAwMDAw MDAwMCwKICAgIDM4MC4zNDkyNDMxNjQxLCAzNTAuMzcwMjM5MjU3OCwgMC4wMDAwMDAwMDAwLAog ICAgMzg2LjM4NTMxNDk0MTQsIDM1OS42MjY4MzEwNTQ3LCAwLjAwMDAwMDAwMDAsCiAgICAzODIu NzgzMTExNTcyMywgMzcwLjk0OTU4NDk2MDksIDAuMDAwMDAwMDAwMCwKICAgIDM2OS44MzM4MDEy Njk1LCAzNzYuODgwNzk4MzM5OCwgMC4wMDAwMDAwMDAwLAogICAgMzczLjUzOTIxNTA4NzksIDM2 MS45MDcyNTcwODAxLCAwLjAwMDAwMDAwMDAsCiAgICAzNTUuOTMwMTc1NzgxMiwgMzUwLjEwNjY1 ODkzNTUsIDAuMDAwMDAwMDAwMCwKICAgIDM2My43NjA0MDY0OTQxLCAzNTkuMjIxOTU0MzQ1Nywg MC4wMDAwMDAwMDAwLAogICAgMzYwLjA0NDMxMTUyMzQsIDM3My44NzUxNTI1ODc5LCAwLjAwMDAw MDAwMDAsCiAgICAzNDQuNDk4ODA5ODE0NSwgMzgzLjk2Mjk4MjE3NzcsIDAuMDAwMDAwMDAwMCwK ICAgIDMzNy44ODkwNjg2MDM1LCAzNzUuOTk3NDk3NTU4NiwgMC4wMDAwMDAwMDAwLAogICAgMzQ4 LjgzMjI0NDg3MzAsIDM3My43MzIxNDcyMTY4LCAwLjAwMDAwMDAwMDAsCiAgICA1ODEuNDIzNzA2 MDU0NywgMzY0LjMzMjczMzE1NDMsIDAuMDAwMDAwMDAwMCwKICAgIDU5MS4yNjcyNzI5NDkyLCAz NzEuMjA0Mjg0NjY4MCwgMC4wMDAwMDAwMDAwLAogICAgNjAwLjIyMjk2MTQyNTgsIDM2OC41NzA2 MTc2NzU4LCAwLjAwMDAwMDAwMDAsCiAgICA1NzAuNDExMDcxNzc3MywgMzcwLjkwNjc2ODc5ODgs IDAuMDAwMDAwMDAwMCwKICAgIDU2OS41OTMxMzk2NDg0LCAzNTcuMzUzMDU3ODYxMywgMC4wMDAw MDAwMDAwLAogICAgNTU4LjIzMzIxNTMzMjAsIDM0OS42NjA1ODM0OTYxLCAwLjAwMDAwMDAwMDAs CiAgICA1NDAuMTA5NDk3MDcwMywgMzc5LjIzNDc3MTcyODUsIDAuMDAwMDAwMDAwMCwKICAgIDU1 Ni4yNTkyNzczNDM3LCAzNjQuNDg2ODc3NDQxNCwgMC4wMDAwMDAwMDAwLAogICAgNTUwLjE1NTQ1 NjU0MzAsIDM3My45NzE4MDE3NTc4LCAwLjAwMDAwMDAwMDAsCiAgICA1MzguMzY2NTE2MTEzMywg MzYzLjk1NjQyMDg5ODQsIDAuMDAwMDAwMDAwMCwKICAgIDUyOS44MjY2NjAxNTYyLCAzNzIuNjY0 Nzk0OTIxOSwgMC4wMDAwMDAwMDAwLAogICAgNTE2LjM5OTk2MzM3ODksIDM2NC43NjkzMTc2Mjcw LCAwLjAwMDAwMDAwMDAsCiAgICA1NDYuMTAzMDg4Mzc4OSwgMzUzLjgyMjkwNjQ5NDEsIDAuMDAw MDAwMDAwMCwKICAgIDQxOS44NTM3NTk3NjU2LCAzNTAuNjcwMDEzNDI3NywgMC4wMDAwMDAwMDAw LAogICAgNDcyLjM1NjUwNjM0NzcsIDM4MC4wNjMzMjM5NzQ2LCAwLjAwMDAwMDAwMDAsCiAgICA0 MDQuNDAxMjE0NTk5NiwgMzcxLjg0NzMyMDU1NjYsIDAuMDAwMDAwMDAwMCwKICAgIDM5NS41MTg1 NTQ2ODc1LCAzODIuNDIzMTI2MjIwNywgMC4wMDAwMDAwMDAwLAogICAgNDAyLjUzNjEwMjI5NDks IDM2MS4xNDE5Njc3NzM0LCAwLjAwMDAwMDAwMDAsCiAgICA0MzAuMjEyNjc3MDAyMCwgMzYxLjM5 MjQ4NjU3MjMsIDAuMDAwMDAwMDAwMCwKICAgIDQwOS43NDg5MDEzNjcyLCAzNTAuOTczNjAyMjk0 OSwgMC4wMDAwMDAwMDAwLAogICAgNDMzLjg1OTYxOTE0MDYsIDM4MS4yNTEyMjA3MDMxLCAwLjAw MDAwMDAwMDAsCiAgICA0MTUuMTQ2MTQ4NjgxNiwgMzYxLjc3NTc4NzM1MzUsIDAuMDAwMDAwMDAw MCwKICAgIDQyOS45NjI2NzcwMDIwLCAzNTAuMzY1MzU2NDQ1MywgMC4wMDAwMDAwMDAwLAogICAg NDQ3Ljk5ODU2NTY3MzgsIDM2Ni4zNDA4NTA4MzAxLCAwLjAwMDAwMDAwMDAsCiAgICA0MjEuMDky NjgxODg0OCwgMzgxLjY0MTYzMjA4MDEsIDAuMDAwMDAwMDAwMCwKICAgIDQ0MC4yNTY1NjEyNzkz LCAzNTkuOTY0MDUwMjkzMCwgMC4wMDAwMDAwMDAwLAogICAgNDM3LjU4MTY5NTU1NjYsIDM3MC43 NTU1NTQxOTkyLCAwLjAwMDAwMDAwMDAsCiAgICA0NDYuNjYwMzM5MzU1NSwgMzgwLjg1ODQ1OTQ3 MjcsIDAuMDAwMDAwMDAwMCwKICAgIDQyNi4zMTU4MjY0MTYwLCAzNzEuODA3NzY5Nzc1NCwgMC4w MDAwMDAwMDAwLAogICAgNDE1LjMwODgwNzM3MzAsIDM3Mi41MjUzNjAxMDc0LCAwLjAwMDAwMDAw MDAsCiAgICA0ODEuNjQxOTA2NzM4MywgMzcwLjUxODA5NjkyMzgsIDAuMDAwMDAwMDAwMCwKICAg IDQ2MC4wNjE3OTgwOTU3LCAzNDkuNDI3NTIwNzUyMCwgMC4wMDAwMDAwMDAwLAogICAgNDUwLjE3 ODY4MDQxOTksIDM1NC43MTYwMDM0MTgwLCAwLjAwMDAwMDAwMDAsCiAgICA0NjUuOTE3NTcyMDIx NSwgMzY0Ljg0ODkzNzk4ODMsIDAuMDAwMDAwMDAwMCwKICAgIDQ3Mi40ODk2ODUwNTg2LCAzNzEu MDc5NzExOTE0MSwgMC4wMDAwMDAwMDAwLAogICAgNDU2LjY5MjUzNTQwMDQsIDM2MS44OTQzNzg2 NjIxLCAwLjAwMDAwMDAwMDAsCiAgICA0NzAuMjk2OTY2NTUyNywgMzU0LjQ2NDg0Mzc1MDAsIDAu MDAwMDAwMDAwMCwKICAgIDQ5OS43OTc2Njg0NTcwLCAzNjAuMTE2ODUxODA2NiwgMC4wMDAwMDAw MDAwLAogICAgNTAzLjY0MDE5Nzc1MzksIDM1MC4wOTI0MDcyMjY2LCAwLjAwMDAwMDAwMDAsCiAg ICA1MDkuMzYyOTc2MDc0MiwgMzU4LjI0OTE3NjAyNTQsIDAuMDAwMDAwMDAwMCwKXTsKCnN0YXRp YyB2b2lkIHJlbmRlcigpIHsKICAgIHN0YXRpYyBpbnQgcm90ID0gMDsKICAgIGdsQ2xlYXIoR0xf Q09MT1JfQlVGRkVSX0JJVCB8IEdMX0RFUFRIX0JVRkZFUl9CSVQpOwogICAgZ2xMb2FkSWRlbnRp dHkoKTsKICAgIGdsVHJhbnNsYXRlZigwLjBmLCAwLjBmLCAtNi4wZik7CiAgICBnbFNjYWxlZigu MDA1LC4wMDUsLjAwNSk7CiAgICBnbFJvdGF0ZWYocm90KyssIDAsMCwxKTsKICAgIHJvdCAlPSAz NjA7CgogICAgZ2xEaXNhYmxlKEdMX0RFUFRIX1RFU1QpOwogICAgZ2xFbmFibGUoR0xfQ09MT1Jf TUFURVJJQUwpOwogICAgZ2xEaXNhYmxlKEdMX0xJR0hUSU5HKTsKICAgIGdsQ29sb3IzZigwLDAs MSk7CiAgICBnbFBvaW50U2l6ZSg1KTsKCiAgICBnbEVuYWJsZUNsaWVudFN0YXRlKEdMX1ZFUlRF WF9BUlJBWSk7CiAgICAvL2dsVmVydGV4UG9pbnRlcigzLCBHTF9GTE9BVCwgMCwgbWVzaF8ucG9p bnRzKCkucHRyKTsKICAgIGdsVmVydGV4UG9pbnRlcigzLCBHTF9GTE9BVCwgMCwgVkVSVFMucHRy KTsKCiAgICBnbEJlZ2luKEdMX1BPSU5UUyk7CiAgICAvL2ZvcmVhY2godmg7IG1lc2hfLnZlcnRp Y2VzX2JlZ2luKCkpIHsKICAgIGZvcihpbnQgaTsgaTxWRVJUUy5sZW5ndGgvMzsgaSsrKSB7CiAg ICAgICAgZ2xBcnJheUVsZW1lbnQoaSk7CiAgICAgICAgLy9nbEFycmF5RWxlbWVudCh2aC5pZHgp OwogICAgICAgIC8vZ2xWZXJ0ZXgzZnYobWVzaF8ucG9pbnRfcHRyKHZoKS5wdHIpOwogICAgfQog ICAgZ2xFbmQoKTsKCiAgICBnbERpc2FibGVDbGllbnRTdGF0ZShHTF9WRVJURVhfQVJSQVkpOwp9 CgpzdGF0aWMgdm9pZCByZXNpemUoR0xDYW52YXMgY2FudmFzKSB7CiAgICBjYW52YXMuc2V0Q3Vy cmVudCgpOwogICAgUmVjdGFuZ2xlIHJlY3QgPSBjYW52YXMuZ2V0Q2xpZW50QXJlYSgpOwogICAg aW50IHdpZHRoID0gcmVjdC53aWR0aDsKICAgIGludCBoZWlnaHQgPSBNYXRoLm1heChyZWN0Lmhl aWdodCwgMSk7CiAgICBnbFZpZXdwb3J0KDAsIDAsIHdpZHRoLCBoZWlnaHQpOwogICAgZ2xNYXRy aXhNb2RlKEdMX1BST0pFQ1RJT04pOwogICAgZ2xMb2FkSWRlbnRpdHkoKTsKICAgIGZsb2F0IGFz cGVjdCA9IGNhc3QoZmxvYXQpIHdpZHRoIC8gY2FzdChmbG9hdCkgaGVpZ2h0OwogICAgZ2x1UGVy c3BlY3RpdmUoNDUuMGYsIGFzcGVjdCwgMC41ZiwgNDAwLjBmKTsKICAgIGdsTWF0cml4TW9kZShH TF9NT0RFTFZJRVcpOwogICAgZ2xMb2FkSWRlbnRpdHkoKTsKfQoK --0016361e894c375ab40460c92bed--
Jan 18 2009
prev sibling 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 next 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)
 

very good at throwing away unneeded code?

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

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