By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,334 Members | 2,746 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,334 IT Pros & Developers. It's quick & easy.

Compilation issues generating SEGMETATION FAULT

P: 4
Hi,

Im compiling a C++ program with g++ 2.9.5 on SunOS 5.8. I have made a project with NetBeans 5.5.1 and getting from it the make files.

The compilation and linking process ocurrs succesfully. At run time, the porgram fails whit "SEGMENTATION FAULT".

I have acces to the originals make files (gererated with Autoconf / Automake), using this file the program executes succesfully.

This seems to be a good "turn around" for the problem, but i need to include new classes to the program.

When i add the files requireds for this classes to the compilation, the program crashes again in run time...

does anybody know any compilation detail that could be the cause of this behavior???

NOTE: I have made the same test with g++ 3.4.2 (MinGW) on WinodwsXP, g++ 3.4.5 (MinGW) on Windows 2000 and g++ 4.1 on SUSE 10 with the same results...

Thanks ....
Aug 8 '07 #1
Share this Question
Share on Google+
7 Replies


Expert 10K+
P: 11,448
Hi,

Im compiling a C++ program with g++ 2.9.5 on SunOS 5.8. I have made a project with NetBeans 5.5.1 and getting from it the make files.

The compilation and linking process ocurrs succesfully. At run time, the porgram fails whit "SEGMENTATION FAULT".

I have acces to the originals make files (gererated with Autoconf / Automake), using this file the program executes succesfully.

This seems to be a good "turn around" for the problem, but i need to include new classes to the program.

When i add the files requireds for this classes to the compilation, the program crashes again in run time...

does anybody know any compilation detail that could be the cause of this behavior???

NOTE: I have made the same test with g++ 3.4.2 (MinGW) on WinodwsXP, g++ 3.4.5 (MinGW) on Windows 2000 and g++ 4.1 on SUSE 10 with the same results...

Thanks ....
While gcc (or g++ for that matter) version 2.9.5 is a very old and bad version,
I do suspect that the fault in your own code. Not knowing what your code is all
about, I can't give you an answer. You do have to supply some details and a bit
of relevant code mayhap?

kind regards,

Jos
Aug 8 '07 #2

weaknessforcats
Expert Mod 5K+
P: 9,197
"SEGMENTATION FAULT".
Almost always this is memory corruption. Check every place you are using pointers or arrays and verify you are not overruning the end of the array and that the pointers contain valid addresses.
Aug 8 '07 #3

P: 4
While gcc (or g++ for that matter) version 2.9.5 is a very old and bad version,
I do suspect that the fault in your own code. Not knowing what your code is all
about, I can't give you an answer. You do have to supply some details and a bit
of relevant code mayhap?

kind regards,

Jos
Jos,
I understand what you mean, but Im talking about 600 000 + lines of code wiht more than three years in production enviroment with no problems.

The detail i seem is most rare is tha two compilation ways (two diferent make files) cant produce two binarys that behaive in such a way.

Other fact is: Once i find a tregger point in the code for the problem, (ever the first static inicialization), just comenting it moves the problen to the next static initialization.

I would like to remark. This code has years in production, and the olnly difference i introduce is the make file.

Thanks..
Aug 8 '07 #4

RRick
Expert 100+
P: 463
Welcome to the world of porting. SW that has run for years on one system can be a bear to get it to run on another system or compiler.

Your static variable problem sounds like a difference in compilers. C++ has changed a lot over the years and you'll probably have to make changes to the source code to get it compile with newer compilers. Find out what is wrong and fix it. Commenting out the code is only delaying the problem until later (as you found out).

Your problem could also be in the makefile. Lots of times, system variables are defined in the makefile and when you change platforms or compilers the variables change and cause havoc.

One trick is to get the logs of the compilation on a machine that works. then compare these logs to the new logs that are giving you trouble. Check the compiler flags real closely between the two systems.
Aug 9 '07 #5

P: 4
Thanks every one...

Believe it or not, i've found in your answers exactly what i looking for.
Aug 11 '07 #6

Expert 10K+
P: 11,448
Thanks every one...

Believe it or not, i've found in your answers exactly what i looking for.
Care to share your new knowledge?

kind regards,

Jos
Aug 11 '07 #7

P: 4
Sorry.... I forget to share...

All that answers have perfect sense in this case, but only one of thems can be prove. I actually was looking for some experts and unpartial opinions about this issue that help me to argument the posbility of a bug in the application.

Now, i think that i have this tool on mi hand's thanks to all of you....

I have not for certain if some action woulb be take to find and repair the bug. but i woul share with you, everihting i can about this rare case. I'm very shure that the answer y so simlple but so hide that we all laugth a lot when we know it..

Thanks again..
Aug 13 '07 #8

Post your reply

Sign in to post your reply or Sign up for a free account.