RFH: segfault on s390x (hyperestraier)

[Satoru KURASHIKI]

hi,

I'm appreciate if someone helps me to trace build failure on s390x.

Now, hyperestraier package fails to build on s390x, logs say that make check
was killed by its inactivity.

./estcmd: INFO: [365:248]: attr: file:///tmp/wicked-00000152-12275.est
./estcmd: INFO: [367:248]: search: 0 hits
./estcmd: INFO: [370:248]: out
make: *** [build-arch-stamp] Terminated
./estcmd: INFO: the termination signal 15 catched
./estcmd: INFO: the termination signal 15 catched
Build killed with signal TERM after 150 minutes of inactivity
Build killed with signal KILL after 5 minutes of inactivity

https://buildd.debian.org/status/fetch.php?pkg=hyperestraier&arch=s390x&ver=1.4.13-7&stamp=1343612759

I tested this on hercules running sid, and find that compiled "estcmd"
fails with
segmentation fault.

This segfault occurs only on s390x, so I guess it is some of platform
specific one.
Are there any pattern or best practice about such problems?

Backtrace is as follows:
(I can't understand what this say... est_vector_cosine seems to accumulate
multiplications of arrays by loop. So range mismatch while looping?)

# gdb ./estcmd -c core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390x-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/deb/hyperestraier/estcmd...done.
[New LWP 21992]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Core was generated by `./estcmd search -vx -kn 8 -sim 2 casket'.
Program terminated with signal 11, Segmentation fault.
#0 est_vector_cosine (avec=0x8a603280, bvec=0x8a6032b0,
vnum=<optimized out>) at estraier.c:5839
5839 aabs += (double)avec[i] * (double)avec[i];
(gdb) bt
#0 est_vector_cosine (avec=0x8a603280, bvec=0x8a6032b0,
vnum=<optimized out>) at estraier.c:5839
#1 0x0000020000059900 in est_search_similar (db=0x8a51ddb0,
svmap=0x8a522ea0, nump=0x3fffff02894, knum=<optimized out>,
unum=<optimized out>, mnum=4096, tfidf=1, nmin=0,
auxmin=32, auxwords=0x8a5225c0) at estraier.c:10280
#2 0x000002000005c378 in est_db_search (db=0x8a51ddb0,
cond=0x8a522520, nump=0x3fffff02a28, hints=0x8a5225f0) at
estraier.c:2831
#3 0x000000008000c2ca in procsearch (dbname=0x3fffff05b8e "casket",
pidxs=<optimized out>, phrase=<optimized out>, attrs=0x8a51aa80,
ord=0x8a5225f0 "", max=10, sk=0, aux
=32,
ec=<optimized out>, opts=0, cd=0, sim=2, dis=0x0) at estcmd.c:2058
#4 0x000000008000e826 in runsearch (argc=<optimized out>,
argv=<optimized out>) at estcmd.c:963
#5 0x000000008000935c in main (argc=<optimized out>,
argv=0x3fffff04ec8) at estcmd.c:272
(gdb)

regards,

[Philipp Kern]

Post by Satoru KURASHIKI
This segfault occurs only on s390x, so I guess it is some of platform
specific one. Are there any pattern or best practice about such problems?

Casts of pointers usually are a problem. Like casting size_t* to int* and vice
versa.

Kind regards
Philipp Kern

PS: The liberal use of casts from (unsigned) char* to int* does not make me
that happy. Like «return (int *)"";» 

[Stephen Powell]

Post by Satoru KURASHIKI
This segfault occurs only on s390x, so I guess it is some of platform
specific one. Are there any pattern or best practice about such problems?

Casts of pointers usually are a problem. Like casting size_t* to int*
and vice versa.
Kind regards
Philipp Kern
PS: The liberal use of casts from (unsigned) char* to int* does not make me
that happy. Like «return (int *)"";»…

On a related subject, Satoru, s390 and s390x are "big-endian"
machine architectures, whereas most computers, including i386
and amd64, are "little-endian" architectures. That is to say
that s390 and s390x store integers in storage with the high-order
byte at the low address and the low-order byte at the high
address. For example, the decimal number 19,088,743, when
converted to a 32-bit binary integer and expressed in hexadecimal
notation, is 01234567. When that number is in a register, both
on amd64 and s390x, it is stored with the high-order byte on the
left, the next high-order byte adjacent to that, and so on,
with the low-order byte on the right. But when the number is
stored into RAM, the two architectures do it differently.
On s390x, the number is stored in big-endian format, with the
high-order byte at the lowest storage address and the low-order
byte at the highest storage address: 01 23 45 67. amd64 stores
the bytes in RAM in reverse order: 67 45 23 01. This is
"little-endian" format. Sometimes hidden assumptions of little-
endian format creep into programs that cause them to not work
properly on s390x.
--
.''`. Stephen Powell
: :' :
`. `'`
`-