Upgrade to OpenEdge 11.6.3, 11.7.0 or later.
As part of the definitive fix for PSC00347434, a workaround for the Linux
1293594 Bug has been implemented. The C stack print option parameter applies only to Linux systems. If it is supplied on other platforms, it is silently ignored.
The
-cstackPrintopt startup parameter, controls which API to use when printing the C-level stack trace when handling SIGUSR1 signal on Linux:
If -cstackPrintopt 0 is specified, the AVM will use existing Redhat’s “backtrace” API to get C-stack
This is the default setting and is the same behavior when cstackPrintopt is not specified at all.
If -cstackPrintopt 1 is specified, the AVM will use “gstack” command to generate the C-stack
This will avoid the crashes, generating the C-stack will be a bit slower.
More importantly, this mode has additional requirements to get the C-stack reliably:
- The gdb debugger packages must be installed on the system (not every Linux distribution has them by default)
- Permission issues can interfere with generating the C-stack if the OpenEdge clients are not run as root.
If -cstackPrintopt 2 is specified, the AVM will not generate the C-stack
Only ABL-related details will be included in the protrace file (command line arguments, startup parameters, ABL stack) thereby avoid both the Linux bug, and the chance of hitting an unknown USR1 a-sync issue
The
gstack command could be used by a user running as root to get the C stack before sending the SIGUSR1 signal to get the ABL Stack. While the ABL and C stacks won't reflect the same point in time, this work around isn't as helpful unless the client is stuck in a very tight loop or waiting. However multiple stacks should always be dumped (rule of 3's ) to show if the stack is changing.
Enabling
core files may also help provide evidence if the crash happens again, particularly when associated with a crashing process, understanding that disk space is needed and the core must be unwound on the machine it is generated on. For recommendations on core file generation refer to Article
Why is a core or protrace file not created when a Progress process abnormally terminates? is an
undocumented workaround, caseSensitive, Client-Session parameter (CS) only for Linux:
- It is available for the following ABL process types: _progres (including webspeed), _proapsv
- It is only available on Linux, iow it cannot be used on prowin (which would be client-server to the linux database).
- For AppServer or WebSpeed agents, specify -cstackPrintopt in the ubroker.properties, srvrStartupParam or in the pf if srvrStartupParm specifies a pf
- For _progres (pro, mpro, mbpro) client session process types, specify -cstackPrintopt on the command line, scripts or in the client's .pf file
- It is recommended to specify relevant CS parameters in a .pf for the executable that is starting the session. While cstackPrintopt can be set in default "dlc/startup.pf" and should not cause issues with argument parsing, it is not recommended.
- To confirm cstackPrintopt has been set, for example: MESSAGE SESSION:startup-parameters.
- C stack print option (-cstackPrintopt) will interact with the Diagnostics feature introduced in 11.7.4 (where protrace generation can be configured). The feature also sends SIGUSR1 to the other processes to generate their protraces.
- The -cstackPrintopt parameter only applies to protrace generation from SIGUSR1 and nothing else. For example it does not apply to protrace files generated during crashing due to a fatal signal (SIGSEGV, SIGBUS).
C stack print option:
- It's not currently available for spawned ABL DB servers (_mprosrv)
- It is not available for rocket engine utilities, _mprosrv, _sqlsrv2, _rfutil, _dbutil, _rpserver, _rpagent or for any java related process (AdminServer, ubrokers)
- When addressing similar deadlocking in localtime function in the rocket engine, the -cstackPrintopt was additionally enhanced as a database startup parameter on Linux in OpenEdge 11.7.5.0, 12.1.0.0 This means it no longer has to be specified on shared-memory clients. Refer to Article Database Server may crash when a protrace is generated
