Forum Jump

Select Group :
Select Forum :
Sorted By :
Sort Order :
From The :
 
Thread Tools  Search this thread 
jdanowitz
Total Points:
60
Status Points:
10
Green Belt
December 24, 2008 5:30 AM PST
Crashes in Intel C++ Compiler, doesn't crash in Microsoft VS2005 C++ Compiler -- HELP!

Hi everyone -- sort of weird problem. When I run this under the Microsoft VS2005 C++ compiler, everything is fine (both debug and release). When I debug it I do get an exception that I pass to the application and never hear from it again.

Under the 11.0.066 Intel C++ compiler in Visual Studio 2005 when I run the application, this crashes and I am not able to get out of the crash.

Here is the description, and I would appreciate it if anyone could give some suggestion of what to do.

  • Please read the following description of the problem. In the Microsoft C++ compiler, despite the problem when I DEBUG it, I am able to pass the exception to the application and not get any more exceptions after that. When I run the app (compiled under Microsoft VS2005 C++) I get no sign of any problem both in the debug and release configurations. The only sign of a problem is when I DEBUG (F5) and then I get a first time exception that I pass to the application and never hear from this again.
  • However, When I compile in the Intel C++ compiler (11.0.066 - w_cproc_p_11.0.066_ia32.exe is the install for it), when I run the application, in debug (ctrl F5) I get all kinds of assertions that I don't get in Windows. When I run it in Release, these assertions do not appear, the program crashes and that's it.
  • I would appreciate understanding either how to fix whatever problem there is, or to make the compiler ignore this at run time just like in the Microsoft compiler.
  • Please read more description below.


I have an MFC application in VS2005 with a CFormView.

There is a CDialogBar (shown when the app comes up) on the left of the view. The DialogBar has a CPropertySheet with 2 CPropertyPage's on it.

The second CPropertyPage has a derived class from CListBox on it. I call it CMenuListBox because it has a floating menu upon right clicks.

The CDialogBar is created when the application comes up in the main cpp file: Runner.cpp as follows:

if
(!ProcessShellCommand(cmdInfo))
return FALSE;
// The one and only window has been initialized, so show and update it
m_pMainWnd->ShowWindow(SW_SHOW);
m_pMainWnd->UpdateWindow();
// call DragAcceptFiles only if there's a suffix
// In an SDI app, this should occur after ProcessShellCommand
((CMainFrame*)m_pMainWnd)->OpenDialogs();

The CDialogBar that contains the CPropertySheet with the CPropertyPages as described above is a member of the CMainFrame class (MainFrm.cpp).

OpenDialogs calls "create" for the CDialogBar (the member of CMainFrame: m_pStatusDlg):

if(m_pStatusDlg==NULL)
{
m_pStatusDlg =
new CStatusTabDlg();
m_pStatusDlg->Create(
this,IDD_DIALOG_STATUS_TAB, CBRS_LEFT | CBRS_TOOLTIPS | CBRS_FLYBY, IDD_DIALOG_STATUS_TAB);m_pStatusDlg->SetWindowText(_T("Status Tab Dialog"));
ShowControlBar(m_pStatusDlg,TRUE,FALSE);
}


Now, when I debug this, when I push the tab for the second page (the statusDlg) I get an error (which I will describe below). If I press break and then F5, I get "pass the exception to the current application?" -- when I answer yes, everything goes on well. In Release mode and in Debug when I run as ctrl F5 there is no mention of this "exception". SO I just left it as it is and that's that. WHen I compile using the Intel Compiler, I get a crash -- so I have to fix this to get the Intel Compiler to work and see it's advantages...

The exception that I get says:
First chance exception at 0x5d0c373e in Runner.exe: 0xC0000005:
Access violation writing location 0x00875bbc.

The crash is in afxtls.cpp as follows:

inline void* CThreadSlotData::GetThreadValue(int nSlot)
{
      EnterCriticalSection(&m_sect);
      ASSERT(nSlot != 0 && nSlot < m_nMax);
      ASSERT(m_pSlotData != NULL);
      ASSERT(m_pSlotData[nSlot].dwFlags & SLOT_USED);
      ASSERT(m_tlsIndex != (DWORD)-1);
     
if( nSlot <= 0 || nSlot >= m_nMax ) // check for retail builds.
      {
           LeaveCriticalSection(&m_sect);
          
return NULL;
      }
      CThreadData* pData = (CThreadData*)TlsGetValue(m_tlsIndex);
      
if (pData == NULL || nSlot >= pData->nCount)
      {
            LeaveCriticalSection(&m_sect);
           
return NULL;
      }
     
void* pRetVal = pData->pData[nSlot];
      LeaveCriticalSection(&m_sect);  
<<<ß-----------HERE IS THE CRASH
      return pRetVal;
}


This happens when I push on the tab button to go onto the second page. If I try to access the page before in code, the crash happens then. If I put the page as the first page, it happens immediately. I did have multiple resource indices, so I changed them to all be unique and still get the crash.
Has anyone seen anything like this? 

Any ideas what this means or where this could come from? Could this be a bug in the version of MFC that I have?

Thanks for any help with this.

 

 

jimdempseyatthecove
Total Points:
34,847
Status Points:
34,847
Black Belt
December 28, 2008 7:15 AM PST
Rate
 
#1


See what is in

  pData
  pData->pData
  pData->pData[nSlot]

Your problem somewhat looks like the sanity checks pass when they should fail. Usualy the root cause being use of uninitialized data or corruption of data. See if you have made your TlsAlloc call prior to getting into this section.

Jim Dempsey

 



Eric Palmer (Intel)
Total Points:
897
Status Points:
397
Brown Belt
January 5, 2009 5:07 PM PST
Rate
 
#2
Can you also try the Intel Compiler 10.1?  This could help narrow down the problem.

 

If you just want to make your app work, and still tune some portion of the code, you could also do a mixed build by moving your performance-sensitive code into a set of files that you compile with the Intel Compiler, and let the rest of the app be built by the Microsoft compiler.  (In an Intel compiler project, individual c/cpp files can be multi-selected, right-click, go to Properties, General, Compiler and Environment Settings, select MS or Intel compiler.)



Jennifer Jiang (Intel)
Total Points:
19,627
Status Points:
19,127
Brown Belt
January 9, 2009 10:40 AM PST
Rate
 
#3 Reply to #2
Try to compile "afxtls.cpp" with VC and see if it crashes.
     open afxtls.cpp's property, under "General", change the compiler to VC.

Jennifer


jdanowitz
Total Points:
60
Status Points:
10
Green Belt
January 19, 2009 5:39 AM PST
Rate
 
#5

Hi,

This problem is solved. What happened is that somewhere in the program I did a delete [] and not just delete. Weird but the visual compiler just passed over this and there was no crash.
Anyway, this seems to be solved.

Thanks,
Jeff



jimdempseyatthecove
Total Points:
34,847
Status Points:
34,847
Black Belt
January 19, 2009 8:08 AM PST
Rate
 
#6 Reply to #5

Although the crash may not have occured, you may have trashed memory (or will trash memory shortly) by using delete [] in place of delete. delete [] requires that an array of objects be allocated to the pointer (even if it is an array of 1 element). In the array allocation, preceeding the pointer to the 1st element is a header containing an additional count information. Depending on the heap manager the count field may require a different header than the single object new allocation. If the headers are different then what would appeare to be the count field of the header (for single object allocated) may very will contain junk (some number other than 1 when interpreted as an array allocation object list for deallocation). Then if the dtor is not null then the damage will likely occure immediately. If the dtor is null and if the header for the single object allocate is a different size as the array of objects allocation header then the crash may occure some time later as you will likely be returning what would appear to be a corrupted allocation.

Jim Dempsey




jdanowitz
Total Points:
60
Status Points:
10
Green Belt
January 19, 2009 8:35 AM PST
Rate
 
#7 Reply to #6

You are right and I did not explain myself correctly. The delete [] was a BUG. The program should have crashed in the visual studio C++ compiler version as well, but it did not.

Once I got rid of the incorrect "[]" then the Intel compiled version ran as well. The crash that I saw was not the one that I mentioned -- this happened both in the visual version and in the Intel version and it is a first time exception which when passed to the application, the application continues to run. This has to do with some list box that I have on a property sheet and I have never found a way to fix it -- the Microsoft people actually say that it might not really be a problem if after the first time exception, everything is ok.

So indeed, you are correct and delete is needed and NOT delete [].

Thanks for the comment...

jimdempseyatthecove
Total Points:
34,847
Status Points:
34,847
Black Belt
January 19, 2009 9:06 AM PST
Rate
 
#8 Reply to #7

>> The program should have crashed in the visual studio C++ compiler version as well, but it did not.

The correct statement is "The behavior of the program is undefined."
i.e.

a) it is not required to crash
b) it is not required to to be benign
c) it may trash something in your program that will not appear in testing
d) it may trash something in your program that will only appear at user site

I would suggest you perform a Find in Files for all occurences of "delete*[]"
Then for each, in seperate find window, locate all allocates to that pointer to check consistancy of use.

Then invert and find all allocates using [ and then for each check the delete.

PCLINT might be able to detect this (I don't use it, but I think it will detect this)

Using a container for the arrays can be helpful in eliminating this problem. If programmed correctly it will not add any computational overhead to the program (if may potentially for some vector optimizations).

Jim Dempsey





Intel Software Network Forums Statistics

8289 users have contributed to 31235 threads and 99108 posts to date.
In the past 24 hours, we have 7 new thread(s) 24 new posts(s), and 31 new user(s).

In the past 3 days, the most popular thread for everyone has been comparison cilk++, openmp, pthreads first results The most posts were made to comparison cilk++, openmp, pthreads first results The post with the most views is Very amusing...  Escalated as

Please welcome our newest member Michael Johanson