Thank you Wolfgang.
I think I know what went wrong. The SPARC HW has pretty strong alignment
requirements. I am quite sure that I have respected alignment quite
well. But in the class seq_arr_t I have obviously not respected alignment.
The array header is 12 bytes long and the elements start at base+12. And
this is wrong, if the elements have wordsize (e.g. 64 bit integers).
The bug is relatively easy to fix. But before providing a fix, I would
prefer to verify my assumption about the bug.
I have written a tiny test program "should_crash_on_sparc.c" which does
not crash on my 64 and 32 bit machines, but it should crash on SPARC. It
is in plain C to avoid any complications.
The tests in cal/test/container pass, because the test cases do not use
containers with 64 bit elements. If you replace
"cal/test/container/test_sequence_arrayed.cpp" with the corresponding
file in the attachment, "make test" should fail as well on your machine.
In order to verify the fix I am planning to do, I have included the tiny
C program "test_alignment.c". Could you please send me the output of
If I am right, I can provide a fix very fast.
Wolfgang Jansen wrote:
> Helmut Brandl wrote:
>> 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.
> Here the values:
> count() = 1
> p->count() = 1
> *p->last() = 0
> p = 0x275590
> &(p->cap) = 0x275598
> p->last() = 0x27559c
> The values sound meaningful. Many 0 bytes follow after p->last().
>> 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
>> If you edited some CFLAGS please restore the original values and use
>> atecomp instead. And before any recompilation, delete all files in
>> 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.
> I did so and obtained
> test_seq_arr_intern 0 test(s) executed
> test_sequence_arrayed 1 test(s) executed
> test_set_arrayed 2 test(s) executed
> test_string 1 test(s) executed
> test_packed_bits 1 test(s) executed
> without crash.