• Advertisement

GD-Silver

Member
  • Content count

    91
  • Joined

  • Last visited

Community Reputation

122 Neutral

About GD-Silver

  • Rank
    Member
  1. Quote:Original post by yadango Quote:Original post by GD-Silver I remember having a similar problem awhile back, and the problem was related to the EXE trying to manipulate the DLL's heap, or vice versa. I seem to remember the problem being related to the run-time libraries that the projects were using, but I can't remember the details. Thus far my fiddling with the project settings has been futile. I saw something like that on newsgroups a while ago. Had something to do with using different versions of the runtime libraries stemming from one heap allocating something and another heap trying to delete it. As long as you're using the same /MD or /MDd switches on your DLLs, you shouldn't get that error. Did you import your old vcproj file or start a new solution and new vcprojs from scratch? Yes, this is what we had to do last time to fix the problem. It is still compiling with these flags, but the problem has resurfaced. It seems that VC 2005 doesn't come with the same run-time libraries as earlier versions. There is no longer a "single thread" runtime library in the dropdown box. I had VC convert the projects. I suppose I could try recreating them and see if that makes a difference. Interestingly enough, it seems that the DLLs have to use the "Multi-threaded" and the EXE has to use the "Multi-threaded DLL" run-time libraries. Any other settings and the thing won't compile. My project has been running fine for months without any problems. It is only now that I've upgraded that the problems have begun. The consensus seems to be that it is something to do with the run-time libraries, which is consistant with the problems that I was having with this earlier in the project. I'm just hoping someone knows something about VC 2005 and what is different about it. And hopefully they know a way to work around it...
  2. Quote:Original post by squirrel_of_death Quote:Original post by GD-Silver Quote:Original post by squirrel_of_death if I were you, I'd change the function to a const char * parameter, and forget std::string completely - see if that solves your problem. With DLLs, yes it's an issue of ( if this is really the problem ) of different runtime libraries ( that the dll was compiled with, for example with your older compiler ) having different implementations of the stl, and thus different memory management implementations; hence your bug. Following this, you could simply recompile your dll with your new compiler, that should fix the bug if you link it to the same runtime library that your app is running. But, again, go to a const char * parameter, and see if that fixes things first of all. *edit* d'oh, but if you change to const char *, then you must recompile anyway... *edit2* also, if you don't want to recompile, then you could just allocate the string as new string str;, and not bother deleting ( again for testing purposes ), and pass *str as the parameter. No delete == no destructor. I've already tried recompiling the DLLs with the new compiler... No luck. As for changing to char*, that would certainly fix the problem, but would take hours upon hours to implement, given that this is but one of MANY functions that use std::string. I would have to pour over thousands of lines of code, converting assignment operators to strcpy() and so on. A real headache. this should not take so long, as you are only changing the entry point to your dll function. Change the signature of your dll function to (const char *cstr), add a line of code to create a std::string(cstr) inside the dll function, and have it named as your old parameter, and the rest of the dll will not know the difference. Further, you have now centralized the string allocation / deallocation within the single DLL, which should resolve the problem. Changing one function would not take long, true enough. However, the problem is common to every function in my DLLs that uses the string class. There are dozens, if not hundreds, of these functions. And I would have to go through every one of them and convert the function to use char*. This would involve not just changing the parameters, but also changing any manipulation functions that occur inside the functions. I could use your workaround for passing parameters in, but there are also many functions that return strings as well. And the EXEs that I have that use my DLLs depend on those functions using strings. So I would also have to go through all the code for the EXEs that use those DLLs and change them as well. Not a trivial task.
  3. Quote:Original post by squirrel_of_death if I were you, I'd change the function to a const char * parameter, and forget std::string completely - see if that solves your problem. With DLLs, yes it's an issue of ( if this is really the problem ) of different runtime libraries ( that the dll was compiled with, for example with your older compiler ) having different implementations of the stl, and thus different memory management implementations; hence your bug. Following this, you could simply recompile your dll with your new compiler, that should fix the bug if you link it to the same runtime library that your app is running. But, again, go to a const char * parameter, and see if that fixes things first of all. *edit* d'oh, but if you change to const char *, then you must recompile anyway... *edit2* also, if you don't want to recompile, then you could just allocate the string as new string str;, and not bother deleting ( again for testing purposes ), and pass *str as the parameter. No delete == no destructor. I've already tried recompiling the DLLs with the new compiler... No luck. As for changing to char*, that would certainly fix the problem, but would take hours upon hours to implement, given that this is but one of MANY functions that use std::string. I would have to pour over thousands of lines of code, converting assignment operators to strcpy() and so on. A real headache.
  4. Quote:Original post by bpoint A memory overwrite bug somewhere, perhaps? You could try adding: HeapValidate(GetProcessHeap(), 0, NULL); in various parts of your code, especially around the call to RunScript. Also, have you recompiled all of the DLLs under VC2005? Just a guess, though... I personally stay very far away from STL, so I probably won't be of much more help. :( I don't think so, simply because everything worked perfectly fine under VS .NET 2003. And yes, I have recompiled everything under VC++ 2005. I would just go back to VS .NET 2003 if only I could find my prereqs CD...
  5. Not a bad thought, and interestingly enough... Now the problem comes when it calls the destructor on the temporary string that I've created (the "script" variable from your example). Very strange indeed...
  6. Quote:Original post by rip-off A reference going out of scope shouldn't call a destructor. It is like passing a pointer. Since I am passing in the string like this: RunScript("Startup.lua") Probably what is happening is it is creating a string on the fly and the destructor is being called on that. For the record, I tried changing the function to pass-by-value and it didn't make a difference. Quote:Original post by rip-off I haven't made any DLLs, but I've heard that you can have problems if memory is newed in one DLL/inside the main app and freed in another DLL/ inside the main app. Yes, I think that is the problem that I'm experiencing, although I can't really see how I'm doing that in my code.
  7. I recently moved from VS .NET 2003 to VC++ 2005 Express. I imported my latest project (a program replete with std::string). Everything compiles just fine, but now the program crashes when it hits the std::string destructor. My output spew says this: First-chance exception at 0x7c81eb33 in GUIBuilder.exe: Microsoft C++ exception: GUIException at memory location 0x0012f7f0.. The thread 'Win32 Thread' (0xf48) has exited with code 0 (0x0). HEAP[GUIBuilder.exe]: Invalid Address specified to RtlValidateHeap( 01510000, 01525F68 ) Windows has triggered a breakpoint in GUIBuilder.exe. This may be due to a corruption of the heap, and indicates a bug in GUIBuilder.exe or any of the DLLs it has loaded. The output window may have more diagnostic information My project consists of an EXE with four supporting DLLs. The DLLs contain the heart of my GUI drawing code, and the EXE is an editor to allow the creation of GUIs using my system. The program is crashing when it returns from the function with the following prototype: void RunScript(const string& filename); This function takes the name of a script file and passses it to the scripting engine inside the GUI system. When the destructor is called on the parameter, the program goes belly-up. I've also tried commenting this line out, and the program crashes as soon as the destructor on a string is called. I remember having a similar problem awhile back, and the problem was related to the EXE trying to manipulate the DLL's heap, or vice versa. I seem to remember the problem being related to the run-time libraries that the projects were using, but I can't remember the details. Thus far my fiddling with the project settings has been futile. Please help, as this project represents a significant code base and it would be a real pain to have to go through and weed out all the std::strings that I've used throughout the project.
  8. objbase.h in d3d9.h

    Thanks very much... I wonder why my forum search on objbase.h did not turn up that other post?
  9. I recently installed Visual C++ 2005 Express Edition and the February 2006 SDK. Previously, I was using VS .NET 2003 and the November 2004 SDK (I think). Now, when I compile my project, I get the following error: c:\dxsdk\include\d3d9.h(40) : fatal error C1083: Cannot open include file: 'objbase.h': No such file or directory The thing that perplexes me is that this is occurring inside a DirectX header, which makes me think that this may be a problem using VC++ Express. I did a quick search on my harddrive, and sure enough, there is no objbase.h anywhere on it. Any insight into this problem would be appreciated. Thanks.
  10. Does anyone know how to calculate the color value using a color filter, the way that ID3DXSprite does it? I am working on a GUI system in DirectX, and want to be able to have the color of child GUI objects be affected by the color of their parent objects. If I've figured it right, one could break the primary color and the filter color into the four channels (ARGB) and take the lower of the two values for each channel. There may be a simpler way to calculate it, or I may have it wrong, so if anyone knows how it's done, I'd appreciate the help.
  11. I already have the .NET 1.1 architecture and SDK installed, but it still asks for the prereqs CD. Somehow, I managed to install whatever it needs the first time I installed it. I just don't know how. I'm hoping I can manually install what it needs so I can install VS. I can't seem to find any information on the MS website about it. I keep hoping my prereqs CD will surface, but I've pretty much turned my place upsidedown looking for it. I'm hoping that someone with greater knowledge than me on the subject knows of a work-around.
  12. My hard drive recently went belly up, so I'm having to reinstall all my software, including Visual Studio 2003 .NET. Problem is, I can't seem to find the prerequisites CD to it, nor do I remember needing it the last time I installed it. Exactly what components does it refer to when it says that some components are not the correct version? Is there some way I can install them without the prerequisites CD? (I assume there is, since I did it once before). Any help is appreciated.
  13. Getting program to use retail DLLs

    Sure enough, downloaded the most recent version and problem solved. Thanks a lot. Strange... I thought Windows Update covered DirectX.
  14. Getting program to use retail DLLs

    Out of the frying pan... I answered my own first question (had a link to d3dx9d.lib in one of my projects), but that leads to another. Now it seems to be searching for the retail DLLs just fine, but I still get a "Unable to find d3dx9_24.dll", which (sure enough) does not seem to be a part of the basic DirectX installation. Am I doing something wrong with my installation procedure here?
  15. OK, this may be a stupid newbie question, but here goes: I've been working on a project using C++ and Feb 2005 SDK for some time and everything is going along great. Now I am trying to copy the program over to another computer that does not have the SDK installed. When I run the program, I get "Unable to find d3dx9d_24.dll". I assume that the "d" at the end of the DLL's name means it is a debug DLL, which the program can't find because the SDK is not installed on that computer. This problem seems to occur whether I use an installer or just copy it over directly. When I build the program on the other computer, I am using release configuration, and I have the control panel settings set to use the retail DLLs. What else do I need to do to tell my EXE and accompanying DLLs to use the retail DirectX DLLs instead of the debug ones? Thanks
  • Advertisement