digitalmars.D.bugs - DMD calling incorrect method
- Tyler Knott (18/18) Mar 02 2006 Test case (source + make file (mt2.bat) + compiled Win32 binary):
- Walter Bright (4/4) Mar 02 2006 The most likely cause of this is the source import files getting out of ...
- Tyler Knott (6/10) Mar 02 2006 That's what I though too, but even when I remove every trace of DWT (.li...
- Tom S (13/25) Mar 03 2006 Seems like a problem we've been battling on #D with Lars and Ant that
- Agent Orange (3/24) Mar 03 2006 have you tried using build.exe and building the entire project from
Test case (source + make file (mt2.bat) + compiled Win32 binary): http://webpages.charter.net/tknott/guitest2.zip (977K) This newsgroup seemed most appropriate for this problem. I'm working on a GUI frontend to a small C program (which I ported to a D class) in DWT and some methods in certain classes (dwt.widget.Button.setBounds, dwt.widget.Combo.add, and dwt.widget.Button.setText are the ones I've encoutered so far) always result in bizarre errors or access violations. I've just been working around them up to this point, but when I couldn't get around it any longer I looked at what the code was doing in a debugger. It seems that DMD is using an incorrect offset while calling the setText method for my settingsButton object and calling the setImage method for it instead(!). To check for yourself run "guitest2.exe" (from the linked zip file) in a debugger, set a breakpoint at 0x00404052, then look at what method (edx+0x4e8) points to when that breakpoint is reached. I'm using DMD 0.148 with DWT 0.36-20060228 and Build v2.9(1197)(Aug 10, 2005) on Windows XP Home SP2, though this also happened with DMD 0.145 and DWT 0.35-20060203 (yes, I did replace the 0.35 DWT .lib and import files with 0.36 ones before compiling the test case). This doesn't always happen: the controlexample example included with DWT compiles and runs just fine.
Mar 02 2006
The most likely cause of this is the source import files getting out of sync with the binary library files or dll's linked in. For instance, if a method was added in the source file, but the library file wasn't recompiled, then all the offsets for the member functions will be off.
Mar 02 2006
In article <du8f49$gnm$1 digitaldaemon.com>, Walter Bright says...The most likely cause of this is the source import files getting out of sync with the binary library files or dll's linked in. For instance, if a method was added in the source file, but the library file wasn't recompiled, then all the offsets for the member functions will be off.That's what I though too, but even when I remove every trace of DWT (.libs, imports, even the documentation and example programs) from my system, and reinstall/build the latest version from scratch it still gives me an access violation and builds with the wrong offset. I'll test this on another computer tomorrow (with a fresh install of DMD and DWT).
Mar 02 2006
Tom S <h3r3tic remove.mat.uni.torun.pl> Tyler Knott wrote:In article <du8f49$gnm$1 digitaldaemon.com>, Walter Bright says...The most likely cause of this is the source import files getting out of sync with the binary library files or dll's linked in. For instance, if a method was added in the source file, but the library file wasn't recompiled, then all the offsets for the member functions will be off.That's what I though too, but even when I remove every trace of DWT (.libs, imports, even the documentation and example programs) from my system, and reinstall/build the latest version from scratch it still gives me an access violation and builds with the wrong offset. I'll test this on another computer tomorrow (with a fresh install of DMD and DWT).Seems like a problem we've been battling on #D with Lars and Ant that occured in DUI. The reason seemed to be imports that are done inside classes. I took a quick peek at DWT sources and indeed, at least the Widget class has imports inside its body. Try moving them to the global scope and see what happens. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y ------END GEEK CODE BLOCK------ Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Mar 03 2006
have you tried using build.exe and building the entire project from sources with no libraries ( -full )? Tyler Knott wrote:Test case (source + make file (mt2.bat) + compiled Win32 binary): http://webpages.charter.net/tknott/guitest2.zip (977K) This newsgroup seemed most appropriate for this problem. I'm working on a GUI frontend to a small C program (which I ported to a D class) in DWT and some methods in certain classes (dwt.widget.Button.setBounds, dwt.widget.Combo.add, and dwt.widget.Button.setText are the ones I've encoutered so far) always result in bizarre errors or access violations. I've just been working around them up to this point, but when I couldn't get around it any longer I looked at what the code was doing in a debugger. It seems that DMD is using an incorrect offset while calling the setText method for my settingsButton object and calling the setImage method for it instead(!). To check for yourself run "guitest2.exe" (from the linked zip file) in a debugger, set a breakpoint at 0x00404052, then look at what method (edx+0x4e8) points to when that breakpoint is reached. I'm using DMD 0.148 with DWT 0.36-20060228 and Build v2.9(1197)(Aug 10, 2005) on Windows XP Home SP2, though this also happened with DMD 0.145 and DWT 0.35-20060203 (yes, I did replace the 0.35 DWT .lib and import files with 0.36 ones before compiling the test case). This doesn't always happen: the controlexample example included with DWT compiles and runs just fine.
Mar 03 2006