Re: [Tecomp-user] Tecomp-user Digest, Vol 9, Issue 1

[Helmut B. <hel...@gm...>]

Wolfgang Jansen wrote:
> Hello Helmut,
> 
> thanks for the hint: adding a blank after all occurrences
> of '-o' fixed the bug.
> (BTW, for 20 years I have applied the '-o' option with a blank
> running very different C compilers. To my knowledge, the blank
> is forbidden only in case of the '-I' and '-L' options.)

Ok, I have already changed the svn repository. So in the next release
tecomp will have a blank between the -o option and the filename.

> 
> To the bigendian question:
> yes, I'm working an a bigendian Sun/sparc platform
> and, yes, the compiler does immediately crash.
> (sorry, for the bad news).
> To see what happens, I re-compiled the stuff with
> '-g' and '-O0' options and run the compiler under 'gdb'.

Thanks for the stacktrace. I am not yet sure what is going on here.
Obviously the "count" method of seq_arr_inter_t returns a completely
screwed up value. This is strange, because your stacktrace says, that
the attribute "cnt" has the meaningful value "1", and the "count" method
just calls then "count" method of seq_arr_intern_t which just returns
the value of the attribute "cnt".

If you run your compiled system in gdb, you could see, what count() and
p->count() return at the location of the segfault. And you can see the
pointer values of p and p->last(). The 2 pointers should be just a
couple of bytes apart.

Some other remarks:

There is no need to change the compiler flags. If you issue

  make atecomp

you get a compiler named atecomp in gen_dir/bin which has all debugging
facilities and all assertions in the compiler enabled. I don't know what
you did exactly. But better use atecomp for debugging (then I know
better what you have done and can compare it with the results on my
machine). The advantage of atecomp is that it is heavily asserted and
might throw an assertion which give us a better hint on what is going on
there.

If you edited some CFLAGS please restore the original values and use
atecomp instead. And before any recompilation, delete all files in
gen_dir/obj.


There are some lower level tests. E.g.

  cd cal/test/container
  make test

tests all the used containers in tecomp. If this test fails, debugging
is easier.

Regards
Helmut

> The crash message, the stack trace, and the values
> of some variables are:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000aa684 in eiffel_parse () at sequence_arrayed.h:748
> 748         new (p->last()) T(e);
> 
> #0  0x00173bc8 in sequence_arrayed_t<unsigned long long>::extend_rear (
>     this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:748
> #1  0x001789bc in sequence_arrayed_t<unsigned long long>::force_rear (
>     this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:760
> #2  0x0019c9a4 in numeric_constants_t::force_rear (this=0x256d6c, val=0)
>     at class.h:265
> #3  0x000dc438 in eiffel_parse () at eiffel.y:3716
> #4  0x000de330 in parse_eiffel_file (f=0x254e68, cls_to_parse=0x256d40,
>     f_name=0x25d434 "./fahr_celsius.e", col=0x254810) at eiffel.y:4275
> #5  0x000cdea0 in eiffel_system_t::parse_system (this=0x254810)
>     at eiffel_system.cpp:239
> #6  0x0009be54 in main (argc=2, argv=0xffbfdf4c) at tecomp.cpp:188
> 
> p = {el_sz = 8, el_sz_al = 8, cnt = 1, cap = 10}
> e = 0
> c0 = 1068848469 = 0x3fb55555
> *(float*)&c0 = 1.41666663
> *(double*)&c0 = 0.083333333333333329
> 
> I'm sure that assigning of 'c0' did work correctly,
> but I don't have any idea where the first error is.
> 
> WJ
>