segmentation fault on Tru64

[brong]

From: torkel@pdc.kth.se
Bugzilla-Id: 1322
Version: 2.1.x
Owner: Ken Murchison

[brong]

From:

I'm in the process of setting up the latest version of cyrus imap on an
alpha, running True64. However when I start it I got an segmentation
fault in ctl_cyrusdb almost immediately, see backtrace below.

>0 0x3ff805c13f8 in __nxm_thread_kill(0x3ffc01b1530, 0xb, 0x1, 0x3, 0x0, 0x0)
in /usr/shlib/libpthread.so
#1 0x3ff805b0c14 in pthread_kill(0x3ffc01b1530, 0xb, 0x1, 0x3, 0x0, 0x0) in
/usr/shlib/libpthread.so
#2 0x3ff805c45b4 in UnknownProcedure3FromFile113(0x3ffc01b1530, 0xb, 0x1, 0x3,
0x0, 0x0) in /usr/shlib/libpthread.so
#3 0x3ff807f373c in UnknownProcedure15FromFile1(0x3ffc01b1530, 0xb, 0x1, 0x3,
0x0, 0x0) in /usr/shlib/libexc.so
#4 0x3ff807f383c in exc_unwind(0x3ffc01b1530, 0xb, 0x1, 0x3, 0x0, 0x0) in
/usr/shlib/libexc.so
#5 0x3ff807f3b2c in exc_raise_signal_exception(0x3ffc01b1530, 0xb, 0x1, 0x3,
0x0, 0x0) in /usr/shlib/libexc.so
#6 0x3ff805b2580 in UnknownProcedure8FromFile14(0x3ffc01b1530, 0xb, 0x1, 0x3,
0x0, 0x0) in /usr/shlib/libpthread.so
#7 0x3ff800d01f0 in __sigtramp(0x3ffc01b1530, 0xb, 0x1, 0x3, 0x0, 0x0) in
/usr/shlib/libc.so
#8 0x3ff800cf688 in strcpy(0x40064658, 0x11fff92c0, 0x1000000, 0x0, 0x0,
0x11fff892d) in /usr/shlib/libc.so
#9 0x12006ce60 in mpool_strdup(pool=0x140054480,
str=0x11fff92c0="configdirectory") "mpool.c":178
#10 0x120065398 in hash_insert(key=0x11fff92c0="configdirectory",
data=0x140054500, table=0x14004a920) "hash.c":115
#11 0x12004c690 in config_read(alt_config=0x0) "config.c":263
#12 0x12004b7c4 in config_init(alt_config=0x0, ident=0x140000160="ctl_cyrusdb")
"config.c":103
#13 0x12004b0c4 in main(argc=2, argv=0x11fffc018) "ctl_cyrusdb.c":226
#14 0x12004abb8 in __start(0x40064658, 0x11fff92c0, 0x1000000, 0x0, 0x0,
0x11fff892d) in imap/ctl_cyrusdb

I also tried to run the hash test (compiled hash.c with -DTEST) and I
got segmentation fault in the same routine.

ratatosk[alpha_dux50]$ uname -a
OSF1 ratatosk.pdc.kth.se V5.0 1094 alpha
ratatosk[alpha_dux50]$ cc -V
Compaq C V6.4-214 (dtk) on Compaq Tru64 UNIX V5.0A (Rev. 1094)
Compiler Driver V6.4-014 (dtk) cc Driver

/torkel

[brong]

From: Rob Siemborski

when you say "in the same function" do you mean mpool_strdup() (the last cyrus
specific routine?)

[brong]

From:

Yes.

I still get a coredump in mpool_strdup with 2.1.9. Compiling the hash test
program gives me the following backtrace:

ratatosk[lib]$ cc -DHAVE_CONFIG_H -DTEST -I.. -o pelle hash.c mpool.c xmalloc.o
hash.c:
mpool.c:
cc: Warning: mpool.c, line 151: In this statement, performing pointer arithmetic
on a pointer to void or a pointer to function is not allowed. The compiler will
treat the type as if it were pointer to char. (badptrarith)
remain = p->size - (p->ptr - p->base);
------------------------^
cc: Warning: mpool.c, line 153: In this statement, performing pointer arithmetic
on a pointer to void or a pointer to function is not allowed. The compiler will
treat the type as if it were pointer to char. (badptrarith)
if(remain < size || p->ptr > (p->size + p->base)) {
----------------------------------^
ratatosk[lib]$ ./pelle
Segmentation fault (core dumped)
ratatosk[lib]$ dbx ./pelle core
dbx version 5.0
Type 'help' for help.
Core file created by program "pelle"

signal Segmentation fault at >*[strcpy, 0x3ff800cf6a0] ldq_u t2, 0(a0)
(dbx) where
> 0 strcpy(0x120002458, 0x3200, 0x12000270c, 0x140000398, 0x1400000a0)
[0x3ff800cf6a0]
1 mpool_strdup(0x1400000a0, 0x11fffbfe8, 0x120001a94, 0x140000398,
0x140002100) [0x120002720]
2 hash_insert(0x140000088, 0x11fffbf80, 0xffffffffffffffff, 0x140051d20,
0x14006e7e0) [0x120001a90]
3 main(0x0, 0xffffffffffffffff, 0x140051d20, 0xc8, 0x140004000) [0x120002288]

/torkel

[brong]

From: Wes Craig

If this is still an issue, please open a new report against a more recent version of cyrus. Thanks!