Intel® C++ Compiler
Support and discussions for creating C++ code that runs on platforms based on Intel® processors.
Announcements
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
7768 Discussions

Strange exception abort with icpc 10.x, 11.x on Linux and Windows

Maik
Beginner
255 Views
I found a really strange behavior of throw() wiith icpc 10.x and 11.x.
Consider the following (very simple and senseless) test program:

Hugo.hpp:
#ifndef __HUGO__
#define __HUGO__
class Hugo
{
public:
Hugo(const std::string sFileName);
};
#endif


Hugo.cpp:
#include
#include "Hugo.hpp"
Hugo::Hugo(const std::string sFileName)
{}


main.cpp:
#include
#include
#include
#include "Hugo.hpp"

using namespace std;


int main()
{
ofstream log( "logfile.txt",ios::out);
try
{
Hugo* xHugo = new Hugo("Test.h5");
throw std::exception();
int senseless=1;
}
catch(...)
{
cerr << "catch" << endl;
}
return 0;
}



On Linux x64 and ia64 using g++ or icpc 9.x , AIX5.3/Power6 using xlC, HP-UX on PA-Risc and IA64 using aCC - everything is fine, the program writes "catch" and exit without error.

But (at least) on Linux x64 and ia64 and Windows x64, using icpc 10.x or 11.x (just with icpc *.cpp, no other compiler flags), the program aborts:

./a.out
terminate called after throwing an instance of 'std::exception'
what(): St9exception
Aborted


If I comment out the line
ofstream log( "logfile.txt",ios::out);
_or_ the line
Hugo* xHugo = new Hugo("Test.h5");
the error disappears.

It is not related to ofstream - when I just exchange the ofstream line with
string myHugo;
the error is the same.

But - when I write
string* myHugo = new string;
instead of the ofstream-Line, the error also goes away.


I have really _no_ idea why this can happen.
Has anybody a hint whats wrong or is there a magic compiler option that corrects this problem?

Please help!

Alexander Haas



0 Kudos
8 Replies
Dale_S_Intel
Employee
255 Views
Hmm, I haven't been able to reproduce the problem yet. Can you give more details on exactly what kind of machines you ran? Here's what happened for me:
[bash]$ uname -a
Linux dpd22 2.6.18-52.el5 #1 SMP Wed Sep 26 15:26:44 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.1 (Tikanga)
$ icpc hugo.cpp main.cpp
$ ./a.out
catch
$ icc -V
Intel C Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build x Package ID: l_cproc_p_11.1.072
Built Apr 19 2010 18:40:26 by on scel20.sc.intel.com in /export/ics1/sharedws/11_1/.next_11756/dev
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
$

[/bash]
Did I miss anything obvious?

Thanks!
Dale
Maik
Beginner
255 Views
I get this behavior with all our environments:

IA64:
/app/linux_23_ia64/intel/Compiler/11.1/038/bin/ia64/icpc -V
Intel C++ IA-64 Compiler Professional for applications running on IA-64, Version 11.1 Build 20090511
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

uname -a
Linux vallinsvtf11 2.6.9-78.0.8.EL #1 SMP Tue Nov 25 19:22:57 EET 2008 ia64 ia64 ia64 GNU/Linux

cat /etc/issue
CentOS release 4.6 (Final)
Kernel \r on an \m

x86-64:
icpc -V
Intel C++ Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20090511 Package ID: l_cproc_p_11.1.038
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

/app/linux_23_x86-64/intel/cce/10.1.015/bin/icpc -V
Intel C++ Compiler for applications running on Intel 64, Version 10.1 Build 20080312 Package ID: l_cc_p_10.1.015
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

uname -a
Linux vallinsvtf05 2.6.9-42.0.10.ELsmp #1 SMP Tue Feb 27 09:40:21 EST 2007 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/issue
CentOS release 4.5 (Final)
Kernel \r on an \m


I also tired this example at home using my noncommercial licenses:
/app/intel/Compiler/11.1/038/bin/intel64/icpc -v
Version 11.1
(and also: /app/intel/cce/10.1.015/bin/icpc)


uname -a
Linux idoru 2.6.24-23-generic #1 SMP Wed Apr 1 21:43:24 UTC 2009 x86_64
GNU/Linux


cat /etc/issue
Ubuntu 8.04.4 LTS

uname -a
Linux idoru 2.6.18-128.1.10.el5 #1 SMP Thu May 7 10:35:59 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/issue
CentOS release 5.3 (Final)



command is alsways the same: icpc *.cpp

As already mentioned, this behavior appears for all my icpc 10.x and 11.x compilers on linux (Windows seems to work, I wasnt able to reproduce the error with my windows test machine today)

When I use icpc 9.1 (or g++), everything is fine.

Any hints?


Alexander Haas



Milind_Kulkarni__Int
New Contributor II
255 Views

Hi Alex,

Thats strange. I am also able to reproduce your error, with the compiler versions that you mentioned, though it seemed to be very simple problem in compiler.

However, your issue does not appear in 11.1.072 compiler, but appears in older ones (like 038), or even latest 10.1.

So, please let us know whether it works for you too for 11.1.072 compiler, though I tested on Ubuntu & Redhat .

Maik
Beginner
255 Views
ok, I well check this next week.

thanks,
Alexander Haas
Maik
Beginner
255 Views
Ah - and now I was able to reproduce the windows error:
when Hugo-Constructor uses a const reference
Hugo(const std::string& sFileName);
then the Windows-Version crashes also at throw.

Compiler Version is 11.0.074, MS SDK is VisualStudio2005, OS is Vista64 Enterprise SP2

Should a new windows compiler also solve this problem?

Alexander Haas
Dale_S_Intel
Employee
255 Views
I didn't reproduce the problem with the latest 11.1 update (11.1.065, aka update 6), though it's not exactly the same system you have. Could you try the latest update and see if that fixes your problem?

Thanks!

Dale
Maik
Beginner
255 Views
Today I tested 11.1.072 using Ubuntu 8.04 (x64) - and the program works ok. So, it seems that 11.1.072 fixes that problem - thanks! I will try 11.1.065 for Windows within this week - I will post a message wether it works or not.

Alexander Haas
Maik
Beginner
255 Views
ok, today I have tested 11.1.065 for windows, and the program works ok. So, for me, this issue is fixed. thanks.
A.Haas
Reply