Bug 46539

Informational

GemStone/S 64 Bit

3.7.1, 3.7, 3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.2, 3.3.1, 3.2.15, 3.x, 2.4.8, 2.4.4.8, 2.4.4.7, 2.2.6.5, 2.x, earlier versions

Linux

GemStone's pstack cannot be used with nonzero kernel.yama.ptrace_scope

GemStone distributes a pstack utility, distinct from the more limited Linux pstack command.  GemStone's pstack is a wrapper for the gdb debugger.

gdb is disallowed from attaching to a process when kernel.yama.ptrace_scope=1,and as kernel.yama.ptrace_scope=0 is a significant security hole, by default this is set to 1 in recent Linux versions. pstack therefore often cannot be used.

In versions of GemStone before 3.4, stack traces using kill -USR1 and on a fatal error were also disabled.  In 3.4 and later, you can get a stack traces using kill -USR1 or on hostCallDebugger, when the NetLDI is in guest mode so the real and effective users of the process are the same.

In versions of GemStone up to and including 3.5.6 and 3.6.1, GemStone could not get stacks for processes started when the NetlDI is in authentication mode, so the real and effective userIds are not the same.

Workaround

sending
    kill -USR1 <pid> prints the desired stacks to the process log, in v3.4 and later in guest mode.

sending (as root user)
   sysctl kernel.yama.ptrace_scope=0 will allow stacks, with the introduction of a general security risk.


                

Last updated: 8/6/21