Cannot catch the following error "ORA-24550: signal received"

[usersina]

I have a nodejs/express setup with front end routes & breejs running scheduled tasks every X seconds.
One of the tasks connects to an Oracle database (11g Express Edition on a Windows 7 machine), then executes a certain query.

Here's an example:

const executeOracleQuery = async (sqlQuery, params) => {
  // Create connection
  try {
    const oracledb = require('oracledb');
    const conn = await oracledb.getConnection({
        user: params.user,
        password: params.password,
        connectString: `${params.host}:${params.port}/${params.database}`,
  } catch (error) {
    console.log(error.stack);
  }
  
  // Execute my query
  try {
    let data = await conn.execute(sqlQuery);
    await conn.close();
    return data;
  } catch (error) {
    console.log(error.stack);
  }
}

After a certain number of executions I get the following error, which isn't catched in the try/catch and crashes my express server.

ORA-24550: signal received: Unhandled exception: Code=c0000005 Flags=0

Encountered exception while getting args for function:0x00007FFBE5937056 Encountered exception while getting args for function:0x00007FF7C9A98260 kpedbg_dmp_stack()+377<-kpeDbgCrash()+129<-kpeDbgSignalHandler()+125<-skgesig_Win_UnhandledExceptionFilter()+158<-0x00007FFBE19E53AC<-0x00007FFBE5937100<-0x00007FFBE591F306<-0x00007FFBE59335AF<-0x00007FFBE5894AAF<-0x00007FFBE593231E<-0x00007FF7CA403CF8<-0x00007FF7C9B7BFC2<-0x00007FF7C9BAE935<-0x00007FF7C9B9EFE8<-0x00007FF7C9BAF0BF<-0x00007FF7C9BD14F8<-0x00007FF7C9A94DA9<-0x00007FF7C9A99A78<-0x00007FF7C9A95368<-0x00007FF7C9BF49AD<-0x00007FF7CA9C0F30<-0x00007FFBE3587E94<-0x00007FFBE58F7AD1

I want to catch the error and log it instead of crashing the server.

[cjbj]

I wonder if DIAG_SIGHANDLER_ENABLED=FALSE in a sqlnet.ora file would stop the process being killed? However, if it does, I don't know what validity the connection will have.

The best overall tactic is to try and work out why you are getting the error, and fix that. Check for (or enable) some client side trace files. There's an interesting comment here about increasing the stack size. (But since you have a generic error, this was an interesting comment but not obviously relevant to your scenario - and really I am just hinting to do some googling.)

[usersina]

I've tried changing the sqlnet.ora file but to no avail. I still get the same error and my server crashes.
Here's my -almost- whole scenario just in case.

One thing I haven't tried yet is using a pooled connection. I will try that as well as changing other parameters (timeouts etc) and get back to this issue. Feel free to close it atm.

[cjbj]

I'll ask around too.

[stale]

This issue has been automatically marked as inactive because it has not been updated recently. It will be closed if no further activity occurs. Thank you for your contributions.

[usersina]

I've tried starting with node instead of nodemon and now I get more details in the console:

npm ERR! code ELIFECYCLE
npm ERR! errno 3221225477

Show full log:

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli   'C:\\Users\\Asus\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'start'
1 verbose cli ]
2 info using npm@6.14.11
3 info using node@v14.15.3
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle dbtoappdy-server@1.0.0~prestart: dbtoappdy-server@1.0.0
6 info lifecycle dbtoappdy-server@1.0.0~start: dbtoappdy-server@1.0.0
7 verbose lifecycle dbtoappdy-server@1.0.0~start: unsafe-perm in lifecycle true
8 verbose lifecycle dbtoappdy-server@1.0.0~start: PATH: C:\Users\Asus\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;A:\Documents\GitHub\database-to-appdynamics\dbtoappdy-server\node_modules\.bin;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Users\Asus\bin;C:\Program Files\Common Files\Oracle\Java\javapath;C:\Program Files\Broadcom\Broadcom 802.11 Network Adapter\Driver;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files\Crucial\Crucial Storage Executive;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Program Files\dotnet;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Users\Asus\AppData\Local\Microsoft\WindowsApps;C:\Users\Asus\AppData\Local\Programs\Microsoft VS Code\bin;C:\adb;C:\Program Files\Git LFS;C:\wamp64\bin\php\php7.4.0;C:\composer;C:\ProgramData\chocolatey\bin;C:\Program Files\Java\jdk1.8.0_211\bin;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\nodejs;C:\Program Files\Symfony;C:\Python\Python38\Scripts;C:\Python\Python38;C:\Users\Asus\AppData\Local\Microsoft\WindowsApps;C:\Users\Asus\AppData\Local\Programs\Microsoft VS Code\bin;C:\shortcuts;C:\Users\Asus\AppData\Roaming\Composer\vendor\bin;C:\symfony;C:\mingw-w64\mingw32\bin;C:\Users\Asus\AppData\Local\Android\Sdk\platform-tools;C:\Users\Asus\.dotnet\tools;C:\Users\Asus\AppData\Local\GitHubDesktop\bin;C:\src\flutter\bin;C:\Program Files\heroku\bin;C:\Users\Asus\AppData\Roaming\npm;C:\oracle\instantclient_19_10
9 verbose lifecycle dbtoappdy-server@1.0.0~start: CWD: A:\Documents\GitHub\database-to-appdynamics\dbtoappdy-server
10 silly lifecycle dbtoappdy-server@1.0.0~start: Args: [ '/d /s /c', 'node ./bin/www' ]
11 silly lifecycle dbtoappdy-server@1.0.0~start: Returned: code: 3221225477  signal: null
12 info lifecycle dbtoappdy-server@1.0.0~start: Failed to exec start script
13 verbose stack Error: dbtoappdy-server@1.0.0 start: `node ./bin/www`
13 verbose stack Exit status 3221225477
13 verbose stack     at EventEmitter.<anonymous> (C:\Users\Asus\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
13 verbose stack     at EventEmitter.emit (events.js:315:20)
13 verbose stack     at ChildProcess.<anonymous> (C:\Users\Asus\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:315:20)
13 verbose stack     at maybeClose (internal/child_process.js:1048:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)
14 verbose pkgid dbtoappdy-server@1.0.0
15 verbose cwd A:\Documents\GitHub\database-to-appdynamics\dbtoappdy-server
16 verbose Windows_NT 10.0.17763
17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Asus\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "start"
18 verbose node v14.15.3
19 verbose npm  v6.14.11
20 error code ELIFECYCLE
21 error errno 3221225477
22 error dbtoappdy-server@1.0.0 start: `node ./bin/www`
22 error Exit status 3221225477
23 error Failed at the dbtoappdy-server@1.0.0 start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 3221225477, true ]

I'll get back to this when I find the solution.

[usersina]

I've tried using pools as mentioned at an earlier date, the crash happens intermittently but it's still there. I also got more information on the error type:

608 Segmentation fault "$NODE_EXE" "$NPM_CLI_JS" "$@"

Update:
Setting $env:ORA_OCI_NO_OPTIMIZED_FETCH = 1 bypasses the segmentation error but I still crash -not surprisingly- with:

npm ERR! code ELIFECYCLE
npm ERR! errno 3221225477

The crash happens whether using pools or a simple connection.

[cjbj]

I noticed your connection close isn't called if the statement execution fails.

Do you really need to open a connection each time. I know there might be reasons, but can revisit using a connection pool with max size 1, and just getting & releasing the connection around when you need it?

What is Bree doing with threads and processes?

[usersina]

How are pools stored exactly?
Doesn't a new pool get created every time a new worker is created? If so, then the only way to re-use a pool is to create a reference in the main app.js which can't be done in my particular case, since I also get the database configuration in the worker itself.

Bringing up Bree's threads and processes is indeed interesting, I'll try looking into it or maybe changing the threading package & get back if I have any updates.

[cjbj]

Workers? That's the first mention made of them for your issue that I recall. There are couple of other issues in this repo that mention them e.g #1345; Windows may be a concern too.

Either way, the areas of interest are:

• use of workers and whatever Bree does.
• potential coding issues, which your incorrect placement of the close() call might indicate could be present.

[usersina]

I've tested the app in a Linux environment (using docker) and the crash is gone!

I was initially running my nodejs app on a Windows 10 Pro 1809:

I should note that my organization has disabled automatic updates so that might an indirect reason for the crash.

   Node: 
   - process.platform => 'win32'
   - process.version => 'v14.16.0'
   - process.arch => 'x64'
   - require('oracledb').versionString => '5.1.0'
   - require('oracledb').oracleClientVersionString => '19.10.0.0.0'

And I'm currently on Linux where I don't get the crash at all:

   Node:
   - process.platform => 'linux'
   - process.version => 'v15.14.0'
   - process.arch => 'x64'
   - require('oracledb').versionString => '5.1.0'
   - require('oracledb').oracleClientVersionString => '21.1.0.0.0'

Thank you @cjbj for this amazing blog!

[stale]

This issue has been automatically marked as inactive because it has not been updated recently. It will be closed if no further activity occurs. Thank you for your contributions.

[cjbj]

@usersina this may be related to the same cause that resolved #1369 (comment)

[usersina]

Running npm install oracle/node-oracledb.git#v5.2.0-dev is stuck. I also can't find the v5.2.0-dev tag in the tags list.

[cjbj]

There is no 5.2.0-dev tag (and won't be). The name 5.2.0-dev refers to the changeable set of files from the commits to the master branch that are made during the development cycle of 5.2. Try npm install oracle/node-oracledb.git#master
When this is installed you'll see it identifies itself as 5.2.0-dev. (Future readers note that the 'master' branch will change to 'main' soon).

[usersina]

Using the mentioned version does indeed fix the issue!

[cjbj]

@usersina that's great to hear. We are wrapping up the 5.2 cycle soon.
I'll close this issue.

[elsondsa]

Can anyone tell me whether upgrading to 5.2.0 will solve the ORA-24550 issue or it will just help in catching the error?