[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: make check problem gettext 0.15
From: |
Bruno Haible |
Subject: |
Re: make check problem gettext 0.15 |
Date: |
Sat, 19 Aug 2006 00:04:15 +0200 |
User-agent: |
KMail/1.9.1 |
Stephen Cartwright wrote:
> 1)
>
> I have attached the output of
> ps auxw | grep -i gettext
> ps -elf | grep -i gettext
>
> at two different times.
>
> 2)
>
> # cc -V
> Compaq C V6.5-011 on Compaq Tru64 UNIX V5.1B (Rev. 2650)
> Compiler Driver V6.5-003 (sys) cc Driver
>
> # uname -a
> OSF1 wg0 V5.1 2650 alpha
>
> Configured as follows:
> CC=cc CXX=cxx ./configure --prefix="/usr/local"
Thanks for these infos. With these, I could reproduce and get a stack
trace. It appears that the child process spawned by msgexec gets caught
in an endless segmentation fault inside execvp():
(dbx) signal Segmentation fault at >*[__hstSetNxmActive, 0x3ff8057d09c]
ldq_l t2, 0(t1)
(dbx) where
> 0 __hstSetNxmActive(0x3ffc0080000, 0x3ffc009a000, 0x3ffc009e310, 0x3b683f04,
> 0x3ff807e0000) [0x3ff8057d09c]
1 __vpSetCritical(0x3ffc009e310, 0x3b683f04, 0x3ff807e0000, 0x6000,
0x3ff8057b714) [0x3ff8057c830]
2 __vpEnterCritical(0x3ff807e0000, 0x6000, 0x3ff8057b714, 0x30d,
0x3ff8057d584) [0x3ff8057b710]
3 __debActiveListLock(0x3ff8057d584, 0x3ffc008a030, 0x3ff805691a4,
0x3ffc01814c0, 0x3ffc0184000) [0x3ff8057d580]
4 __muGetBlock(0x120000000, 0x3035000120000000, 0x3ff8014681c, 0x0,
0x3ff80147948) [0x3ff805691a0]
5 (unknown)() [0x3ff8056a7b4]
6 (unknown)() [0x3ff8056bb34]
7 __pthread_mutex_trylock(0x0, 0x0, 0x1, 0x0, 0x3ff80122ae4) [0x3ff805686d8]
8 __tis_mutex_trylock(0x1, 0x0, 0x3ff80122ae4, 0x0, 0x3ff800ebd6c)
[0x3ff80122ae0]
9 __execvp(0x140002ef0, 0x11fffbe28, 0x12002242c, 0x0, 0x12001d21c)
[0x3ff800ebd68]
10 create_pipe(progname = 0x11fffe040 = "./mex-test1.sh", prog_path =
0x11fffe040 = "./mex-test1.sh", prog_argv = 0x14002a660, pipe_stdin = @1,
pipe_stdout = @0, prog_stdin = (nil), prog_stdout = (nil), null_stderr = @0,
slave_process = @1, exit_on_error = @1, fd = 0x11fffbeb0) ["pipe.c":397,
0x12001d230]
11 create_pipe_out(progname = 0x11fffe040 = "./mex-test1.sh", prog_path =
0x11fffe040 = "./mex-test1.sh", prog_argv = 0x14002a660, prog_stdout = (nil),
null_stderr = @0, slave_process = @1, exit_on_error = @1, fd = 0x11fffbf20)
["pipe.c":500, 0x12001d5a4]
12 process_string(mp = 0x140034100, str = 0x14002af80 = "Project-Id-Version:
Bonnie Tyler\nContent-Type: text/plain;
charset=ISO-8859-1\nContent-Transfer-Encoding: 8bit\n", len = 110)
["msgexec.c":343, 0x12000d790]
13 process_message(mp = 0x140034100) ["msgexec.c":374, 0x12000d8ec]
14 process_message_list(mlp = 0x14000b540) ["msgexec.c":387, 0x12000d954]
15 process_msgdomain_list(mdlp = 0x14000c980) ["msgexec.c":397, 0x12000d9ac]
16 main(argc = 4, argv = 0x11fffc018) ["msgexec.c":222, 0x12000d148]
And this is caused by the mere fact of linking with -lpthread.
In other words, pthreads are incompatible with [v]fork()/exec() on OSF/1.
You should be able to get around the problem by configuring gettext with
the additional option --disable-threads. (Before reconfiguring, you need
to do a "make distclean". And of course, you can kill the two CPU-burning
msgexec processes.)
Thanks a lot for the report! I'll make --disable-threads the default
on OSF/1 for gettext-0.15.1.
Bruno