Re: Real pain with SegFoult
- From: Cubanan <cubanan@xxxxxxx>
- Date: Wed, 25 Jul 2007 12:25:07 +0200
Thanks for your advices Jacob.
Of course I AM debuging my program all the time. I fact, I've fixed a
lot of minor bugs in that way. Unfortunatelly, there are two problems
that make my big bug impossible to find, as follows:
1. My program behave in many diffrent ways depends on parameters I put
while compiling and during runtime. Putting such a stuff to g++ like -g
-Ox and feeding my program with different data makes my program to: runs
normal and makes fine output, cause segFoults or busErrors at different
places. Sometime, it is enough to add -g to g++ and makes my program
work good... and makes debuging useless
Yes, of course... there are always some parameters and input data which
cause segFoult during gdb-ing. BUT (and here comes the real pain):
2. All such a segFoults are uncatchable becouse they appear in free()
procedure. They does'n appear in my code. I can only follow computation
to find the right free(). It is obvious that real bug have place
somewhere earlier... that's why I'm rather looking for a stuff that
detect memory leaks and all the problems assiociated with that than
debugign it one more time.
Any hint may help...
Cubanan
jacob navia napisał(a):
Cubanan wrote:.
Hi guys,
Actualy I'm facing REALY big problem with program for my M.Sc.
For three days I'am looking for a bug, but I'm not able to find it. It
is realy disaster for me becouse it is one of them which appears only
sometime, on some machines and with some parameters making it IMPOSSIBLE
to debug.
This kind of bugs are just a bit more difficult to debug
than the others, but basically they are NOT very difficult
since you have a segmentation fault, what greatly SIMPLIFIES
debugging. You have a starting point.
Much more difficult to debug are WRONG RESULTS, without any trap
at all. THOSE are nightmares.
Not goint into details, let's me tell you that I'am making it
on my home machine (Gentoo, AMD64) and trying from time to time on
remote big gun - Solaris (2.9 sparc).
You should go into the details if you want help here.
As you can predict, it (almost)
always works fine at home but on Solaris it gives me Seqmentation Foults
and Bus Errors (I've never known that there is such a thing.. till now
:). I'm doing a lot of malloc/realloc/free stuff so I think there have
to be some memory leaks...
Memory leaks do not provoke a segmentation fault, not immediately anyhow.
I've googled a lot and I've tried some stuff:
1. It seems, that some time ago (when gcc was 2.9.5) it was a
-fcheck-memory-usage parameter that adds instruction to compiled
programam witch checks for memory leaks, out-of-bound errors and so on...
I belive, it would help me very much, but I think it is disabled now.
Was that mechanism removed or name of paremter changed?
Do not use obsolete tools. gcc 2.95 is no longer maintained since
ages.
2. Realizing that '-fcheck-memory-usage' is not going to help me I
started to look for outside soft. First was ccalloc... but I found it
useless.
It not only doesn't compile on my Solaris but also make some problems on
my linux while linking my stuff causing such blame as:
b.c: In function 'mkstr':
b.c:5: warning: incompatible implicit declaration of built-in function
'strcpy'
b.c:5: warning: incompatible implicit declaration of built-in function
'strlen'
/usr/lib/ccmalloc-gcc.o:(.eh_frame+0x12): undefined reference to
`__gxx_personality_v0'
collect2: ld returned 1 exit status
This means that you are mixing c and c++ code.
Link with g++ or eliminate the c++ code.
.. so I given up with ccalloc
Yes, the obvious reason is that you do not debug. You just try stuff,
without putting the effort to find out WHY things fail.
Type __gxx_personality_v0 in google and see what happens.
3. Next was valgrind. It seems to work fine, but only on my home linux.
I can't be compiled on sparc machine.
It is Intel architecture specific as far as I remember.
Thanks to it, I've fixed some minor bugs, but my stuff still segFoults.
I can't do anything more with that tool.
So, at the moment, I've tried everything I can find on google but I
haven't solve my leaking problem.
You haven't tried the debugger.
Do you have any experience with it?
Yes, I have used a debugger a lot. I even wrote one.
First, start your program under debugger control. Wait till
the crash happens. THEN:
See what is happening, examine the values of the variables,
DEBUG!!!
If the program runs under linux and crashes under Solaris
it could be an alignment problem. Do you make casts anywhere
without taking ints only at correctly aligned positions?
char *pData;
int *pintData = pData+3;
int m = *pintData; // should crash in Solaris... if you use Sparc.
Do you know any other stuff which
may help me?
Yes. Use the Solaris debugger. Read the debugger documentation and
DEBUG!
thank for ANY help
ps
I've also heard someting about mpatrol, and maybe I'll try it later.
Stop wasting your time.
Debug your code. You will have to do it anyway.
jacob
- Follow-Ups:
- Re: Real pain with SegFoult
- From: Ian Collins
- Re: Real pain with SegFoult
- References:
- Real pain with SegFoult
- From: Cubanan
- Re: Real pain with SegFoult
- From: jacob navia
- Real pain with SegFoult
- Prev by Date: Re: view the code
- Next by Date: Re: Conversion rules between unsigned operands and signed operand
- Previous by thread: Re: Real pain with SegFoult
- Next by thread: Re: Real pain with SegFoult
- Index(es):
Relevant Pages
|
