Bug found with writing to Data Segments and try catch statements

[Terri_Hawker]

At our company we use data segments within the Binaries for various uses but when we attempted to compile with the Intel C++ compiler 14.0 we ran into a bug.  It was sort of a unique bug that happened only when you were using try and catch statements AND you were using #pragma directives to write to a data segment. Essentially what will happen is the Type definitions written within the catch parameter will be copied into a sum of memory between the data segments when you compile a program in just the right way.  This does not occur with the Microsoft Visual Studio C++ compiler.  The work around is very easy and the bug is really discrete but I wanted to let you guys know of this.  Here's how to reproduce (I'm using VS 2013 Intel C++ Compiler 14.0 to reiterate):

Create a console application.  In the header file copy this

stdafx.h:

#pragma once

#include "targetver.h"

#include <stdio.h>
#include <tchar.h>


#ifndef ASYMBOL
#define ASYMBOL

#pragma data_seg(push, "dummyData")
static  wchar_t mysection[16] = L"This is my end";
#pragma data_seg(pop)
//Add this to force your compiler to use the pop. aka this is how we worked around it
//static int DummyValue = 5;
#endif

// EOF

main.cpp:

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{

	try {

	}
	catch (int var){

	}


	return 0;

}

//EOF


Now open the resulting binary in a hex editor  Search the unicode for "int" or "This is the End"  You'll notice whatever you change the catch statement's data type to, like char or void etc.  this will get written right next to the data section "This is the End".  If you uncomment the variable this seems to force the compiler to actually pop out of the data segment and no extra data get's wrongfully written to the data segments.

 

[Terri_Hawker]

This also only seems happens in Debug configuration.  

[Shenghong_G_Intel]

Hi Terri Hawker,

I've reproduced the issue, I checked with dumpbin /ALL test.exe. And yes, it seems only happens with /Od (debug configuration). See the bug report as below. I'll submit it to dev team to fix.

Thanks,

Shenghong

// Version 15.0.1.148
// icl test.cpp /EHsc /Od
// dumpbin test.exe /ALL > dump.txt
// search "dummyDat" (not dummyData. It is expected. Same with MS compiler) section in dump.txt
/*
Expected:
RAW DATA #4
  00417000: 54 00 68 00 69 00 73 00 20 00 69 00 73 00 20 00  T.h.i.s. .i.s. .
  00417010: 6D 00 79 00 20 00 65 00 6E 00 64 00 00 00 00 00  m.y. .e.n.d.....
Bug (If changing catch part with other data type like int, it will also change in dummyDat):
RAW DATA #4
  00413000: 54 00 68 00 69 00 73 00 20 00 69 00 73 00 20 00  T.h.i.s. .i.s. .
  00413010: 6D 00 79 00 20 00 65 00 6E 00 64 00 00 00 00 00  m.y. .e.n.d.....
  00413020: 63 68 61 72 00 00 00 00                          char....
1. worked with /O2
2. uncomment "DummyValue" (as below) will work around it.
*/

#pragma data_seg(push, "dummyData")
static  wchar_t mysection[16] = L"This is my end";
#pragma data_seg(pop)

// Add this to force your compiler to use the pop. aka this is how we worked around it
// static int DummyValue = 5;

int main()
{
	try {
	}
	catch (char var){
	}
	
	return 0;
}