Compilation issues generating SEGMETATION FAULT

**JosAH** · Aug 8 '07, 03:57 PM

Originally posted by dupin

Hi,

I´m 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 "SEGMENTATI ON 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

**weaknessforcats** · Aug 8 '07, 04:43 PM

Originally posted by dupin

"SEGMENTATI ON 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.

**dupin** · Aug 8 '07, 07:38 PM

Originally posted by JosAH

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 I´m 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) can´t 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..

**RRick** · Aug 9 '07, 01:19 AM

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.

**dupin** · Aug 11 '07, 02:11 PM

Thanks every one...

Believe it or not, i've found in your answers exactly what i looking for.

**JosAH** · Aug 11 '07, 02:17 PM

Originally posted by dupin

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

**dupin** · Aug 13 '07, 03:31 PM

Sorry.... I forget to share...

All that answers have perfect sense in this case, but only one of them´s 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..