ibmruntimes / node

This repository is moving to: https://github.com/ibmruntimes/node-zos
69 stars 24 forks source link

Keep getting assertion failure of "Assertion faied: %s, fie: %s, ine: %d" on z/OS #82

Closed std3lqi closed 7 years ago

std3lqi commented 7 years ago

I tried ibm-1.2.0.16-ea3-node-v0.12.17-os390-s390x.pax.Z on z/OS one week ago, which worked well with hello world. Then I tried to move my app on z/OS, doing npm install and so on. After excluding some node modules I think maybe not working on z/OS, I kept getting the following failure.

Assertion faied: %s, fie: %s, ine: %d

What confused me is my original hello world got this failure too. Whatever I did to clean my environment, and tried to bring hello world back to work, I failed with same assertion failure.

Then I tried ibm-1.2.0.17-ea4-node-v0.12.18-os390-s390x.pax.Z. Same assertion failure. Here is the stack I got from dbx.

stopped in CEEOSIGG at 0x0000000017975d2c ($t2)
0x0000000017975d2c (???)     a7890000     LGHI    R8,0
(dbx64) (dbx64) where
CEEOSIGG() at 0x17973eb0, PPA1 at 0x17976e74, stack at 0x5010bfd680
CEEOKILL() at 0x17747458, PPA1 at 0x17747a78, stack at 0x5010bfe6a0
pthread_kill() at 0x17747c80, PPA1 at 0x1774aa30, stack at 0x5010bfe960
abort() at 0x17517470, PPA1 at 0x175179f8, stack at 0x5010bfea60
node::debugger::Agent::Agent(node::Environment*)() at 0x15b965f0, PPA1 at 0x15b986e8, stack at 0x5010bfeba0
node::Environment::Environment(v8::Local<v8::Context>,uv_loop_s*)() at 0x159e6f38, PPA1 at 0x159f1118, stack at 0x5010bfeca0
node::CreateEnvironment(v8::Isolate*,uv_loop_s*,v8::Handle<v8::Context>,int,const char* con...() at 0x159e6a58, PPA1 at 0x159f1098, stack at 0x5010b0
node::Start(int,char**)() at 0x159e72d0, PPA1 at 0x159f11d0, stack at 0x5010bfef60
main() at 0x15ad4278, PPA1 at 0x15ad42e8, stack at 0x5010bff120
CELQINIT() at 0x174d9010, PPA1 at 0x174dafac, stack at 0x5010bff220

Thanks!

jBarz commented 7 years ago

It seems be the case that your system has run out of resources (semaphores/shared memory). One way to free these resources is to use the ipcrmcommand. ipcswill list what exactly is being used.

std3lqi commented 7 years ago

Many thanks! I can see many semaphores not freed with ipcs. After freeing them all, I can run npm and node now.

However, after I pressing Ctrl+C to stop node, I still can see some semaphores not freed. Is it expected?

std3lqi commented 7 years ago

My app still hit this assertion failure, after freeing semaphores all. Maybe related specific node modules? Still on the way looking into it. Any hint would be helpful. Thanks!

Here is my ulimit output.

ulimit -a core file size (blocks, -c) 4096 data seg size (kbytes, -d) unlimited file size (blocks, -f) 8589934588 open files (-n) 64000 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 5000 virtual memory (kbytes, -v) unlimited

jBarz commented 7 years ago

We expect semaphores won't be freed if the application closes unexpectedly (e.g. seg fault). However, I noticed that they aren't freed when the application is closed via CTRL-C which is not expected. We are looking into fixing that.

Can you share the output of ipcs -y ?

std3lqi commented 7 years ago

Here is my output.

>node test CEE5206S The signal SIGINT was received.

>ipcs | grep TEST s 69669 0x00000000 --ra------- TEST OS390 s 69670 0x00000000 --ra------- TEST OS390 s 69671 0x00000000 --ra------- TEST OS390 s 69672 0x00000000 --ra------- TEST OS390 s 69673 0x00000000 --ra------- TEST OS390 s 69674 0x00000000 --ra------- TEST OS390 s 69675 0x00000000 --ra------- TEST OS390 s 69676 0x00000000 --ra------- TEST OS390 s 69677 0x00000000 --ra------- TEST OS390 s 69678 0x00000000 --ra------- TEST OS390 s 69679 0x00000000 --ra------- TEST OS390 s 69680 0x00000000 --ra------- TEST OS390 s 69681 0x00000000 --ra------- TEST OS390 s 69682 0x00000000 --ra------- TEST OS390 s 69683 0x00000000 --ra------- TEST OS390 >ipcs -y

IPC status as of Mon Jan 16 10:35:06 2017 Message Queues: MNIDS HWIDS CIDSA CPRIV CKEY GETEX MAXQB QMNUM ENOMEM 1000 355 657 214 129 0 262144 10000 0 Shared Memory: MNIDS HWIDS CIDSA CPRIV CKEY GETEX TPAGES SPAGES SEGPR CPAGES MAXSEG 500 4 497 0 3 0 262144 262144 50 3 1 Semaphores: MNIDS HWIDS CIDSA CPRIV CKEY GETEX MNSEMS MNOPS CSBYTES 500 48 482 15 3 0 25 25 100000000

jBarz commented 7 years ago

What about ipcs | wc -l

It seems like you didn't get the assert btw, right?

std3lqi commented 7 years ago

The node test is a hello world, which works well, except some semaphores are not freed as expected.

The app I'd like to port to z/OS uses more node modules, which seemed exhausting semaphore resource and got assert failure.

>ipcs | wc -l 372

Thanks!

std3lqi commented 7 years ago

I got my app to work to some extends, without assert failure related to semaphores. But I still think some semaphores are freed, because, occasionally, assert failure showed up after restarting node.js server a couple of times during debugging.

Thanks!

jBarz commented 7 years ago

Tech preview 5 is available which cleans up system semaphores. It is available for download here Do re-open this issue if you see hanging system semaphores with the new version.

zorts commented 7 years ago

Thanks for fixing this!