weird DECthreads bugcheck (PW433au, DU 4.0c)

From: Mark Bartelt <mark_at_cita.utoronto.ca>
Date: Fri, 14 Nov 1997 08:38:00 -0500

A program which works fine under DU 3.2c doesn't work on our PW433au
systems (DU 4.0c). It doesn't even manage to start, but aborts with
the following message:

  DECthreads bugcheck (version V3.13-439), terminating execution.
  Failure initializing the manager thread tcb

We've been running with patch duv40cas00001-19970603 until today, when
I installed duv40cas00002-19970819 in hopes that it might fix things.
No joy; the problem is still present.

A trace shows the following:

  Tracing process /proc/15698
  getpagesize () = 8192
  obreak (0x148096bd0) = 0
  getpagesize () = 8192
  obreak (0x1480a4bd0) = 0
  mprotect (0x148098000, 8192, 0) = -1, (Not enough space)

And immediately after that, the bugcheck.

The .bss section starts at virtual address 0x140002c70, and its size
is 0x8085f60, so the argument passed to the first obreak() is 0xe000
past the end of the initial .bss section, and second is 0xe000 past
that; and 0x148098000 is the first multiple of 0x2000 (= 8192) above
0x148096bd0.

The segment sizes shouldn't be a problem, since limits are

  datasize 1048576 kbytes
  stacksize 32768 kbytes
  memoryuse 119752 kbytes
  vmemoryuse 1048576 kbytes

If I stop in mprotect(), I find the following:

  0 __mprotect()
  1 stkGet()
  2 thdIniTcb()
  3 schInit()
  4 (unknown)()
  5 (unknown)()
  6 __init_libpthread()

I have managed to find one correlation: The program includes DXML
routines. If I don't link with "-ldxml", and replace the routines
used by the program with dummy stubs, the program starts up without
a problem.

The first obvious question is why the pthreads stuff is even getting
invoked, since this isn't a multi-threaded application. So my first
suspicion was that somehow the parallel DXML library was getting used
instead of the normal one. Nope; dxml.a is a symlink which points to
/usr/opt/XMDLOA313/dxml/libdxml_ev5.a (the parallel DXML stuff lives
in XMDPLL313).

So, anyone know what's going on? Any other patches that I might have
missed? Any obvious workarounds?

By the way, the relevant version info is: DXML 3.1, Fortran 3.8 (and
I also tried with Fortran T4.1(ft3); same problem).

PS: What is obreak()? It doesn't appear to be documented anywhere
that I can find. Some variant of the brk() and sbrk() family? But
why is there no manpage?

Mark Bartelt 416/978-5619
Canadian Institute for mark_at_cita.utoronto.ca
Theoretical Astrophysics http://www.cita.utoronto.ca/~mark

"Nur eine Waffel taugt!" -- Parsifal, in an Eggo commercial
Received on Fri Nov 14 1997 - 15:04:47 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:37 NZDT