LinuxQuestions.org - g++ produced binaries produce segfault under 64-bit

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - g++ produced binaries produce segfault under 64-bit (https://www.linuxquestions.org/questions/programming-9/g-produced-binaries-produce-segfault-under-64-bit-373997/)

g++ produced binaries produce segfault under 64-bit

Hi everyone,

I've just installed a new copy of SuSE Linux 10.0 and I'm having a slight problem. I have a simple Tic-Tac-Toe game that I created and under my previous distro (Ubuntu 5.04 32-bit) it compiles and runs fine. Under SuSE 10 64-bit however, it compiles, but segfaults. Pre-compiled 32-bit binaries work fine. I've attempted the following:

Code:

g++ main.cc -o naughts_and_crosses.bin

This does nothing, and the binary gets some way before segfaulting.

Code:

g++ -m32 main.cc -o naughts_and_crosses.bin

The binary segfaults right at the beginning.

Code:

linux32 bash

g++ main.cc -o naughts_and_crosses.bin

As above.

Code:

linux32 bash

g++ -m32 main.cc -o naughts_and_crosses.bin

Again, as above. Does anyone know what might be causing this?

Best,

Jamyskis

What gcc do you use? If you are using 4.x I'd downgrade to 3.x. Maybe your shared libs are compiled as 32 bit? Or it could be that your program assumes that sizeof(int) and sizeof(void*) are 4 bytes, whereas they should be 8 bytes on a 64 bit platform. For 64 bit floating point operations (double double), gcc uses externally defined (linked at run-time) functions in 32-bit programs since it can't perform the operations in registers. Since you are compiling as 64-bit, however, I'm not sure if it still uses these functions. Can you narrow down where the crash is? Even if the segfault is the only output, there may be some things hung up in the standard output buffer. Try putting std::cin.get() periodically to pause the program and update the display to figure out where the crash is.
ta0kira

I figured out the problem in the end: it was the version of GCC, although under SuSE 10 it is a real pain to downgrade without causing endless amounts of package breakage suffering. I'm now back to a much more stable 3.3.6 and it's compiling fine :D

Thanks for the help. :D

Correction - it isn't. Installing CPP, GCC, G++ and libstdc++ 3.3.5 everything is broken and it won't work properly unless 4.0 is installed, and nothing will compile with 4.0, trying all of the above. The problem segfaults on a simple cout << instruction, whether it be 3.3 or 4.0 on SuSE, but compiles and runs fine on every 32-bit distro I can think of.

How are you downgrading? If you install everything under /usr/local then you can have 2 independent versions. You just need to put /usr/local in your include and lib paths preceding /usr.

What are you sending to std::cout? Does it crash with something like std::cout << "Helllo"? I guess in any case cout shouldn't segfault unless a custom << operator does something it isn't supposed to. I think it sounds like a gcc problem. What is the line that segfaults?
ta0kira

I've been using the SuSE 9.3 RPMs up until now and overwriting gcc, g++, cpp and libstdc++ using [b]rpm -iv --force rpmname-x.x.x.rpm[b]. Unless I grab the sources direct from GNU and compile them, I have no choice but to use the RPMs. The downgrading doesn't make a difference in any case (I thought it did because downgrading in Ubuntu 32-bit 5.10 seemed to do the trick), and only results in dependency hell.

As for the output buffer, it seems to be quite random on what it segfaults (by that I mean it's quite indiscriminate, but it is always in the same places). It does segfault on cout << "hello" but not on others. Any variables passed to std::cout are only of type string or int - nothing exotic. The lines in particular (it's a simple tic-tac-toe game):

cout << endl << _PLAYERCOUNTSELECT;
cout << endl << _PLAYER1_ENTERNAME;
cout << endl << _PLAYER2_ENTERNAME;

The three string variables are called from a header file. I couldn't see why that would segfault, but I replaced them with:

cout << endl << "How many players?";
cout << endl << "Player 1, enter your name: ";
cout << endl << "Player 2, enter your name: ";

Which made no difference. Strangely enough there are other lines that pass to the output buffer and don't segfault, all calling to the same header file. As an example:

Code:

        

        do

        {

                os_clear_screen();

                display_message();

                cout << endl << _BOARDSIZESELECT;

                getline(cin,boardsize_entry_string,'\n');

                check_boardsize();

        } while ((boardsize<3)||(boardsize>8));

        

        do

        {

                os_clear_screen();

                display_message();

                cout << endl << _PLAYERCOUNTSELECT;

                getline(cin,playercount_entry_string,'\n');

                check_playercount();

        } while ((playercount<1)||(playercount>2));

The above code segment segfaults on cout << endl << _PLAYERCOUNTSELECT but not on cout << endl << _BOARDSIZESELECT, regardless of what is sent. Very strange.

Anyway, thanks in advance for the help :D

If it is actually cout causing the segfault then I don't think there is a lot you can do besides revert to 32-bit compilation and check the gcc site for a bug report. Or, if you can think of another similar tool that uses cout and is 64-bit, try to see if they did anything different. I don't know how attached you are to your distro, but you could try switching to something built around gcc 3.x instead of 4.x; that way you won't have to figure out the dependencies for downgrading. I'm pretty sure Slackware current uses gcc 3 and has 64 bit support. gcc 4 has a lot of problems; enough to not make it worth more than 3 except for experimentation and the pursuit of quality for the sake of GNU. I can't imagine a distro built around it. I think you're better off building gcc from source personally, rather than using an RPM.

Sometimes you can have a bug elsewhere and an unrelated line of code draws it out; even though cout apparently causes the crash, it could be something else that is setting up the crash. Try making a main() function with nothing but cout with different types of data and see if it crashes. If it does, then that pretty much settles the cause. If not, it doesn't rule out a bug in cout, but it makes the cause a little harder to find.
ta0kira

I've had no problem with downgrading to 3.4 under Ubuntu (under 3.3.5 and 3.4.2 it compiles and runs without a hitch), so I'll go on using that for development and see what happens with SuSE. I'm very much a "SuSE person" but I'm not so attached as to stay with it if it doesn't serve my purposes anymore. 32-bit compilation under GCC 4 makes no difference regardless of whether I use the -m32 switch (under SuSE) or a 32-bit version of GCC (under Ubuntu), and no bug had been submitted thus far from what I could see, so I've just submitted one.

I suppose this is the excuse I need for trying out Slack though - just never got around to the fun of installing and configuring it. Thanks for taking the time to help me anyway. I owe ya one. :D

Slack 10.0 was a really easy install for me. The full install is the way to go.
ta0kira