Conference caldec::wrl_atom

293.0. "Customer having problem with Third Degree" by NETRIX::"[email protected]" (Wil Bergman) Wed Feb 26 1997 07:06

Lectori Salutem,
	one of our customer who developes software himself uses Third Degree.
He finds it very usefull, but encounters a problem which he does not
understand 
and therefor cannot solve.
Following is problem as he mailed it to me :

QUOTFor the last 3 months I have been developing applications, written in the
C language on a DEC Alpha platform. In this period Third Degree was used
to make a runtime analysis of these applications.

Using Third Degree definitely speeded up debugging and saved me a lot of
time. Unfortunately, this week a strange problem popped up that is yet
unsolved.

For each application, 2 versions are built. A 'normal' executable and a
'Third Degree' executable. The problem is, that I have a 'normal' executable
that works fine, and a 'Third Degree' version, that produces errors.

The object code of the application is built as follows:

cc -c /usr/users/mpieters/src/kmsmod_clip.c
-o /usr/users/mpieters/obj/kmsmod_clip.o
-I<number of include paths>
-migrate -std1 -warnprotos
-assume noaligned_objects -O0 -YPOSIX -DDEBUG -DCSA_SIMULATE

The 'normal' version of this application is built as follow:

cc -o /usr/users/mpieters/bin/kmsmod_clip.exe
-O0  -L<number of library paths>
-lkar  -llki  -lkms  -lnenclip  -lingres  -lspat  -lcsa
-lfur  -lm  -lfor  -lc_r  -lFutil  -lots  -lrt

The 'Third Degree' version is built as follows:

3rd cc -o /usr/users/mpieters/bin/kmsmod_clip.3rd
-O0  -L<number of library paths>
-non_shared -Wl,-r /usr/users/mpieters/obj/kmsmod_clip.o
-lkar  -llki  -lkms  -lnenclip  -lingres  -lspat  -lcsa
-lfur  -lm  -lfor  -lc_r  -lFutil  -lots  -lrt

Running 'kmsmod_clip.exe' goes fine. Running 'kmsmod_clip.3rd' produces
the logfile 'kmsmod_clip.3rd.3log', that contains the following:

---------------------------------------------------------------- wor -- 0 --
Writing memory at 0x11fffe390 4096 bytes below stack pointer
  - sysgln                                     sysgln_env.for, line 61
  - nen_clip                                     nen_clip.for, line 112
  - main                                        kmsmod_clip.c, line 230

---------------------------------------------------------------- rus -- 1 --
Reading uninitialized memory in stack frame of sysgln at offset 8
  - _OtsMoveMinimumX                        ots_movem_alpha.s, line 260
  - sysgln                                     sysgln_env.for, line 61
  - nen_clip                                     nen_clip.for, line 112
  - main                                        kmsmod_clip.c, line 230

_______________________________________________________________________
-----------------------------------------------------------------------
*** fatal signal SIGSEGV detected: program last seen near this location ***
  - _OtsMoveMinimumX                        ots_movem_alpha.s, line 67
  - sysgln                                     sysgln_env.for, line 61
  - nen_clip                                     nen_clip.for, line 112
  - main                                        kmsmod_clip.c, line 230

........... and a lot more of this 'fatal signal SIGSEGV detected' ....

The difference between 'kmsmod_clip' and other applications, is that
it calls the function 'nen_clip', present in the library libnen_clip.{so,a}
and originates from Fortran source.

The library was delivered with a sample program. Building and running 2
versions, produced exactly the same result. The 'normal' version worked
fine, the 'Third Degree' version produced errors.


When I was trying to find out, what the solution to this problem could be, I
learned that the 'wor' message was gone after moving the definition of a
particular big local variable to the outside of a function. This looked
something like this:

Variable poly as a local variable of main. This produced the same 'wor'
message.

void main (int argc, char **argv)
{
   . . .
   int poly[2][5000];
   . . .

}

Variable poly defined as semi global. The 'wor' message on function main was
gone.

int poly[2][5000];
void main (int argc, char **argv)
{
   . . .
   . . .

}


Given you all this information, I hope you or anybody, can come up with a
solution to this problem.

With regards,

UNQUOTE

Can somebody be of help with this ???

Kind Regards, Wil

[Posted by WWW Notes gateway]

The info from the customer suggests that he is using a really old version
of Third Degree, so I'm hesitant to suggest anything. Concerning the "wor"
error, all I can say is that if a variable is moved off the stack, then it
seems likely that Third Degree will no longer report stack errors when it
is accessed. The customer needs to debug the instrumented program (see
below for more on this). I am a little concerned about the program's use
of the "-assume noaligned_objects" compilation option. This might confuse
Third Degree's detection of read-access to uninitialized memory.

Digital UNIX V4.0 and later contains a supported version of Third Degree,
which can also handle shared libraries and fully linked executables,
so the customer's special build for Third Degree will not be needed.
It also contains a man-page, third(5), which will tell him that he will 
get much better error reports out of Third Degree if he compiles and 
links "-g".

The Third Degree in Digital UNIX V4.0 and later supports a -Xgprog flag
on the "atom" command line. This retains global symbols in the instrumented
application, which will help the customer debug the program at the point
where each error or SEGV occurs. Soon, we will release a new unsupported
version of Third Degree whose -gp switch can be used instead of -Xgprog
to get complete debugging information. Watch for an announcement in note 2,
but do not use the current "Atom ADK"(V2.29), because it has a bug in this
area.