Printable View
Hello All,
I am facing a problem with created Exe.
if the Exe is created with GNU 3.X.X serires, it works properly while the Same Exe created with 4.X series results in crashing in simple cout statement. A simple helloworld program is not working.
Should I take care of something between the compiler updates ??
Regards
Ram
At a guess, you need to post code. A second guess would be that as you are using cout, you should be posting that code in the C++ forum. :)
What exactly is the program that you compiled?
oh sorry for posting in C forum. We have a test suite which was working with Visual studio. we migrated to eclipse and Gnu 3.X and the test suite was working. when we moved to 4.X serires we started having runtime problems like crashing at cout. i just removed our standard main function and started try with basic c program as below to debug what was going wrong. but couldnt find any reason as why it should crash
Code:int main(int argc, char **argv)
{
int a = 3 + 5;
std::cout << "some" << std::endl;
return 0;
}
Moved.
And show us the actual error message(s), along with your compile log, and anything else you might have to show us what you're doing.
Hello,
this is the error I get when I get into GDB for the above code. there are no compilation and linking error
gdb/mi (6/22/11 2:42 PM) (Suspended)
Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)
3 std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >() 0x00842c96
2 ntdll!RtlAppendStringToString() 0x7c9101db
1 <symbol is not available> 0x0022ff1c
That code, as given, should not compile. It is necessary to #include <iostream>, otherwise the compiler has no information about what std::cout and std::endl are.
In terms of your test cases, my guess is that one of the test cases is failing to compile or link when using the newer version of gcc, or maybe some data file it needs is not valid. When a program fails to compile or link, no executable is generated (and any previously existing version of that executable is typically deleted).
It is also possible your test case invoked some form of undefined behaviour, and you just "got lucky" with the older compiler.
The code compiles. The #include was included (but not posted) and executable was generated after a complete clean build. the test suite main function starts all the test functions to execute. Since the first line Cout itself was throwing error, I had removed all the test cases calls and just kept only a simple program and had no execution of tests. However this fails :(
is it something to do with static linkage (often discussed as reason between different GNU compiler)
Static linkage causing the problem? Not particularly likely.
From what you say, the most likely explanation I can see is covered in the last line of my previous post. Undefined behaviour often has the quaint effect of changing with compiler versions (for example, working "as expected" in an old version and failing in a new version, or vice versa).
even if that is the case, how can we debug such things. Any advise pls. Am stuck here and the project delivery date has already passed
thanks
There is no single source of undefined behaviour (in fact, there is almost an infinite number of ways in which code can exhibit undefined behaviour) so there is no single way to debug it once it occurs.
A common approach is to isolate the cause - divide and conquer. For example, eliminate code that is executed before your segmentation fault occurs. If code is removed (commented out, etc) and the symptom disappears, then it is possible that the removed code is the cause of the problem. Also, if changing inputs (for example, content of a data file) eliminates a symptom, it might be that the problem only occurs with particular values of some variable.
Bear in mind that the cause of a segmentation fault (or any runtime error) is always in code executed at or before the point where the symptom becomes visible.
Note that there are no guarantees in doing this. Not all coding errors result immediately in a runtime error, and sometimes it is a combined effect of multiple errors that subsequently yields the runtime error.
Testing after the fact - which is what you are doing - is the worst possible way to isolate programming errors.
if you have any global objects, it's possible that one of them is doing something naughty in its constructor, before main() even runs.
suprise....the exe created with latest compiler works if created via managed make build of eclipse but not via Make file...any clues.. divide and conquer didnt help much though as we have singleton classes and construction is completly under control
Sounds like your GCC 4 may be pulling in incompatible versions of some libraries. It may help to run the compiler in verbose mode (-v I think) to find out exactly how it calls the linker.
For example, it may be that it pulls in its own headers, but links against the GCC 3 library, or vice versa. This could cause segmentation faults.
I believe the last breaking change of the standard C++ library was with GCC 3.4, so if the 3.x you mentioned was older, that could very well be the reason.
In any case, things on Windows may be different, so there may be more recent breakages as well.
I have had this happen to me under cygwin. I had gcc 4.3.4 installed and decided to upgrade to 4.5.0. The cygwin installer failed to update something so gcc was compiling with 4.5 headers but linking against 4.3 libraries which caused a lot confusing segfaults until I found the problem.Quote:
Originally Posted by CornedBee
thanks for the hint. I finally found the problem. we had used linker script in our program. in the managed make, we had passed the command as -Wl,-script while in the make file we had not passed this command and hence the object data allocation was erratic which had caused this problem.
thank you all for all the useful hints which helped me to track this problem.