Random behavior of VS2005 RC1 compiler

Random behavior of VS2005 RC1 compiler

• Jerry Foote

  Ah, my apologies, in my meanderings through the other replies I quite missed that! (duh)
  
  I've found with VC6 that the constructor to CWinApp does not always get called before constructors of other globally declared objects.  Perhaps one of those constructors is calling the suspect code
  
  If not, then I cannot imagine why code that does not execute would cause the hassles.  If its mere existance and not execution is the cause, then I'd also assume a compiler or linker bug.
  

• Kwebster

  If you believe it is a bug in the VC compiler and not your code, Log a bug at http://lab.msdn.microsoft.com/productfeedback/default.aspx where you attached your project. The reponsible folks will then take a look straight ahead.
  
  Thanks,
    Ayman Shoukry
    VC++ Team
  
  
  

• mmatsumura

  Hi Stephane,
    Could you please post a small complete reproducible code sample so that the folks on this forum could take a look.
  
  Thanks,
    Ayman Shoukry
    VC++ Team
  
  

• Rich Lander

  Unfortunately, the exe alone won't help.
  
  If you believe it is a bug in the VC compiler and not your code, Log a bug at http://lab.msdn.microsoft.com/productfeedback/default.aspx where you attached your project. The reponsible folks will then take a look straight ahead.
  
  Thanks,
    Ayman Shoukry
    VC++ Team
  
  

• alex222

  This one is even more bizare.  I have :
  ...
    swprintf(pszPath[0], _T("%s"), strPath);
    swprintf(pszPath[0], _T("%s"), strPath);
  ...
  
  Like this I have the exception.  If I commented out the second line (which is the same as the first one!). The exception goes away!
  
  

• SimonH

  I tried to reproduce this on a smaller scale without success.  It is hapenning in my application but this is quite large to post (even after I remove a lot of stock).  The application (.exe) itself is smaller and could be sent to you.  Do you have any debugging tools that can get a more accurate information about what is wrong.
  As you can tell in my description, it is a very simple sprintf that trigger the problem.  I have thousands of other sprintf in the code that are fine.
  
  

• Blubablub

  Thanks for you post. 
  However, my problem is not when the software is executing a particular piece of code.  The exception occur before I enter the first line of code of my application.  That's even before I enter the constructor of my CWinApp!  In order to isolate that, I have to commented out 90% of my code! That's why I think it's a compiler issue. The code was running fine with VS2003.  In fact this code was running fine with VS6 also.
  I commented out 1 line of code inside a function and the problem goes away (the program will reached my first line of code).
  I'm doing my best to narrow the problem and posting a sample code wihtout confidential information .
  Thank for the tip with the variable guard.  That's a nice one.  I'll use it on my next stack problem!
  
  

• Mehmet Bicak

  Stephane Guerin wrote:

  swprintf(pszPath[0], _T("%s"), strPath);   swprintf(pszPath[0], _T("%s"), strPath);

  
  
  I cannot explain right off why your first piece of sample code might be causing errors, but this bit above might have an explanation, swprintf is defined as;
     int swprintf( wchar_t *buffer, const wchar_t *format [, argument] ... );
  If pszPath is an array of pointers there should be no trouble.  But if pszPath is a character array, then you are using the character value of the first cell in the array as the pointer, and not the address of the array itself.  If so, try this instead;
    swprintf(pszPath, _T("%s"), strPath);
    swprintf(pszPath, _T("%s"), strPath);
  
  All the signs you are describing seem to indicate that something is walking all over your stack, the seemingly random behaviour, and the inability to reproduce the trouble in a small programme.  Try putting a few guard variables around the pieces that cause the trouble, like this;
     int guard = 0x12345678;
     <do your stuff>
     ASSERT(guard == 0x12345678);
  
  If that assertion fails, then something has indeed messed your stack.  However, stack trouble can be hard to trace since the signs might not show up until later, when you are trying to use damaged stack objects or a function return restores the ip to digital hell.  Even guard variables in inner functions can be left untouched while those in outer functions are getting swatted.
  
  If you are assured your stack is fine, you could always try stepping into swprintf... enjoy the ride! :D
  
  Looking back to your first post;
  

  Stephane Guerin wrote:

  void drtc77_SetIPAddressServer(TCHAR * pServer) {   TCHAR strIPAdress[500];   _stprintf(strIPAdress, _T("%S"), pServer); }

  
  Something you could try in this code is a wcscpy to just copy pServer into strIPAdress, since this is essentially what _stprintf should be doing.  If that still fails, do your own version, like;
     TCHAR *tc = strIPAdress;
     while (*tc++ = *pServer++);
  However, by this point, it might well have been found your buffer is too small
  
• Random behavior of VS2005 RC1 compiler