C++ Segmentation Fault on exit of main

Hi,

I have 2 problems with a simple C++ app which i feel may be related.

1/ my app throws a Segmentaion Fault when my code exists from main(). I have stripped it to it's simplest form with no code in main and it still generates a segmentation fault.
I'm not sure what is causing this, possibly i'm missing a compiler switch in my build?

see code sample below.

2/ if i debug my test code in dbx i notice that argc is set to 0 and argv is nil. on further testing i find argc and argv are always 0 no matter what command line arguments i pass to the app (tested with a modifed veriosn that prints the output of argc and argv)

Has anyone got any ideas what could be causing these problems? I tried the same code on a solaris10 box and got the same result so i'm assuming it's something i'm doing wrong with my compile and link settings.

would appreciate any input ..
ta,
SOP

First off .. my enviornment.

OS: SunOS devsun02 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-4
64-bit sparcv9 kernel modules
I also verified i get the same reults when i try my code on a Solaris10 box

C++ compiler: CC: Sun WorkShop 6 update 1 C++ 5.2 2000/09/11

Problem: When my program exists main it throws a Segmentaion Fault.

my code is as follows

Testharness.cpp:
#include <iostream>

int main(int argc, char* argv[])
{
std::cout << "argc="<<argc<<" argv="<<argv<<std::endl;
return 0;
}

my copile and link:

CC -xarch=v9 -c -o src/TestHarness.o src/TestHarness.cpp
OS version : 5.8
Library Path : -L/opt/SUNWspro/lib/v9 -L/usr/lib/sparcv9 -L/opt/sunstudio9/SUNWspro/lib/v9 -L/usr/ucblib/sparcv9/
ld -o Testharness src/TestHarness.o -64 -L/opt/SUNWspro/lib/v9 -L/usr/lib/sparcv9 -L/opt/sunstudio9/SUNWspro/lib/v9 -L/usr/ucblib/sparcv9/ -lCrun -lCstd -lc

when I run:

>./Testharness
argc=0 argv=0
Segmentation Fault

the libraries Testharness is linking to:

ldd Testharness
libCrun.so.1 => /usr/lib/64/libCrun.so.1
libCstd.so.1 => /usr/lib/64/libCstd.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libucb.so.1 => /usr/ucblib/sparcv9//libucb.so.1
libresolv.so.2 => /usr/lib/64/libresolv.so.2
libsocket.so.1 => /usr/lib/64/libsocket.so.1
libnsl.so.1 => /usr/lib/64/libnsl.so.1
libelf.so.1 => /usr/lib/64/libelf.so.1
libdl.so.1 => /usr/lib/64/libdl.so.1
libmp.so.2 => /usr/lib/64/libmp.so.2
/usr/platform/SUNW,Ultra-4/lib/sparcv9/libc_psr.so.1

I set dbx to check access and memuse and i get no further information.

output from dbx
(process id 13308)
argc=0 argv=0
signal SEGV (no mapping at the fault address) in (unknown) at 0x8
0x0000000000000008: <bad address 0x8>

any help would be most appreciated. .

hello,
i wonder if you solved the problem or not?and if solved how?
thanks

hi xyzt,

no .. I never did solve the problem .. pressure of work schedule forced me to work around it by using exit(0) instead of return 0.

I'm still stumped why the arguments are nil and why the exception is thrown if i use return.

my code has a nasty fix:

#ifdef WIN32
return 0;
#else
exit(0);
#endif

I'm not happy with it .. but the code runs with no segentation fault. Have you seen something similar?

The stack in main() has been corrupted with an overrun of one or more the variable(s) on it. Probably in one of the functions. It has overwritten the stack pointer that return uses to go back to the calling routines (_start is the usual name).

When main() attempts a return the SP is not "aimed" where it should be. And your code tries to read program text outside of process memory. Address: 0x08

exit() does not return from main or wherever - it starts image rundown directly. It does not use the SP.
You need to fix the problem before you push your code to production. Try running electric fence or whatever other memory checkers you have.

try this
New code is argv[0]

std::cout << "argc="<<argc<<" argv="<<argv[0]<<std::endl;
It will work. argv is an array of pointer.

The problem is not limited just to the arguments to main().

The OP could dummy up a stack canary to see when and in what function the variables get overwritten.

argv is a double pointer to strings. Just dumping the pointer to stdout won't work out very well. Consider traversing the array, using argc to resolve the end of the list of pointers.

#include <iostream>
#include <cstdlib>
#include <string>
#include <vector>
using namespace std;

int main(int argc,char** argv)
{
vector<string> args;
for (int i=1;i<argc;i++)
{
args.push_back(argv[i]);
}

for (vector<string>::iterator it=args.begin();it!=args.end();it++)
{
string& s=*it;
cout<<s<<endl;
}
return 0;
}

Hi,

i know this is a very old thread now, but I just found it again through a google search for another issue and I thought for completeness sake i'd update it with the solution. You never know it may be useful for other people who may have a similar issues in the future.

It turned out i was linking against incorrect libraries, i was linking against single threaded instead of multi threaded.

When i added the switch -mt in the linking stage the problem was solved.

hey .. better late than never.

Can you get core dump and look at the stack?

Below code -

#include <iostream>

int main(int argc, char* argv[])
{
std::cout << "argc="<<argc<<" argv="<<argv<<std::endl;
return 0;
}

Displayed output at your end -

argc=0 argv=0

I don't know why argv is 0? argv should have non zero address holding pointer to zeroth argument that is - program name