Re: make check problem gettext 0.15

[Bruno Haible]

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