Kbase P126466: The _sqlsrv2 process crashes with error 49 memory violation when the database is started within a So
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
7/10/2008 |
|
Status: Unverified
SYMPTOM(s):
cannot connect with ODBC
cannot connect with JDBC
The _sqlsrv2 process crashes with Memory Violation when the database is started within a Solaris container.
The SQL server crashes with Memory Violation when the database is started within a Solaris container.
Error 49 in the database log file
SYSTEM ERROR: Memory Violation Error (49)
protrace file generated
stack trace
(5) sema_post() +0x5fc from: /lib/libc.so.1
(6) _doprnt() +0x1cbc from: /lib/libc.so.1
(7) fprintf() +0xe0 from: /lib/libc.so.1
(8) __1cJsql_log_tMwrite_header6FpnG__FILE_L_L_() +0x38 from:
/data60/mfgpro/progress/dlc4gl101b.test/bin/_sqlsrv2
FACT(s) (Environment):
cannot manually spawn _sqlsrv2
setuid bit is not set on _sqlsrv2
ldd on _sqlsrv2 finds all libraries
Sun Solaris Intel
Sun Solaris SPARC
Solaris SPARC 10 64-bit
OpenEdge 10.1B
OpenEdge 10.1A
CAUSE:
Bug# OE00157171
CAUSE:
In the non-container environment, certain environment variables are defined before the database broker starts SQL Server processes (_sqlsrv2). In the container environment, these environment variables are not properly defined, causing start of the SQL Server to fail.
The workaround is then to define the needed environment variables before starting the proenv session.
DLC=<directory where Progress is installed>; export DLC
JDKHOME=<directory where JAVA is installed>; export JDKHOME
CLASSPATH=$DLC/java/progress.jar:$DLC/java/base.jar:$DLC/java/openedge.jar:$DLC/java/base.jar
example:
DLC=/usr1/llaubach/101c/dlc ; export DLC
JDKHOME=/tools/solaris/java/j2dsk1.4.2_06 ; export JDKHOME
CLASSPATH=$DLC/java/progress.jar:$DLC/java/base.jar:$DLC/java/openedge.jar:$DLC/java/util.jar
Although doing the above should allow you to run SQL Explorer in the proenv environment, you will notice that it takes just over 30 seconds for the SQL Explorer prompt to appear as it takes this long for the SQL Server (_sqlsrv2) process to start. Once it does start, you will see a SQL*.log file appear in the working directory which reports an error. You can safely ignore this file.
The reason why it takes 30 seconds for the SQL Server to start is due to the method currently used to start a SQL Server as a daemon process. Normally, a SQL Server process is started by the database Broker. This process is a child process of the Broker and is "parented" to the Broker. This new SQL Server process then forks and the child then kills the original SQL Server process which then results in a daemon process, parented to the root process. In the non-container environment, the root process has an ID of 1. In the container environment the root process for the virtual environment has another ID entirely. The problem is that we wait for 30 seconds for an indication that the SQL Server is now parented to process ID 1. After 30 seconds we then continue anyway.
FIX:
1. Upgrade to OpenEdge 10.1B03 or later.
2. As a workaround, in order to run the SQL Server and SQL Explorer, you need to have the JAVA environment set up with environment variables, etc. defined. The $DLC/bin/sql_env file is set up to establish what is necessary for this environment, but you first need to define JDKHOME in order to run this.
Steps to configure proper environment:
- Define the JDKHOME environment variable:
JDKHOME=/tools/solaris/java/j2sdk1.4.2_06
export JDKHOME
- Execute the proenv script:
. /usr1/oe/dlc/bin/proenv
- Execute the sql_env script:
. $DLC/bin/sql_env
- Start the database:
proserve sports2000 -S 8888
- Connect to the database with SQL Explorer:
sqlexp -db sports2000 -S 8888