[GNU] Different Behvaiour of compiler

This is a discussion on [GNU] Different Behvaiour of compiler within the C++ Programming forums, part of the General Programming Boards category; Hello All, I am facing a problem with created Exe. if the Exe is created with GNU 3.X.X serires, it ...

  1. #1
    Registered User
    Join Date
    Jun 2011
    Posts
    7

    [GNU] Different Behvaiour of compiler

    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

  2. #2
    Awesomefaceradcore bivhitscar's Avatar
    Join Date
    Apr 2006
    Location
    Melbourne, Australia
    Posts
    210
    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.
    it's ironic considerate rarity patron of love higher knowledge engulfs me...

  3. #3
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,717
    What exactly is the program that you compiled?
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #4
    Registered User
    Join Date
    Jun 2011
    Posts
    7
    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;
    }

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,535
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    Registered User
    Join Date
    Jun 2011
    Posts
    7
    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

  7. #7
    Registered User
    Join Date
    Jun 2005
    Posts
    6,289
    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.
    Last edited by grumpy; 06-22-2011 at 03:34 AM.
    Right 98% of the time, and don't care about the other 3%.

  8. #8
    Registered User
    Join Date
    Jun 2011
    Posts
    7
    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)

  9. #9
    Registered User
    Join Date
    Jun 2005
    Posts
    6,289
    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).
    Right 98% of the time, and don't care about the other 3%.

  10. #10
    Registered User
    Join Date
    Jun 2011
    Posts
    7
    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

  11. #11
    Registered User
    Join Date
    Jun 2005
    Posts
    6,289
    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.
    Last edited by grumpy; 06-22-2011 at 05:55 AM.
    Right 98% of the time, and don't care about the other 3%.

  12. #12
    Registered User
    Join Date
    Oct 2006
    Posts
    2,402
    if you have any global objects, it's possible that one of them is doing something naughty in its constructor, before main() even runs.

  13. #13
    Registered User
    Join Date
    Jun 2011
    Posts
    7
    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

  14. #14
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #15
    Registered User
    Join Date
    Jan 2010
    Posts
    412
    Quote Originally Posted by CornedBee View Post
    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.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 7
    Last Post: 12-13-2010, 09:02 PM
  2. Replies: 4
    Last Post: 09-12-2009, 01:10 PM
  3. Replies: 2
    Last Post: 02-04-2008, 01:34 AM
  4. hp iPAQ 6300 && C compiler || C# compiler
    By xddxogm3 in forum Tech Board
    Replies: 2
    Last Post: 12-07-2004, 06:28 AM
  5. Dev-C++ compiler. need help
    By Di$eNt in forum C++ Programming
    Replies: 18
    Last Post: 08-18-2004, 02:02 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21