Nw.js: Same code which worked on 0.37.4 crashes on 0.38.0

[julijane]

======== TEMPLATE BUG FORM ========

NWJS Version : 0.37.4 / 0.38.0
Operating System : Linux/Windows

Expected behavior

It does not crash.

Actual behavior

The same code is working fine with 0.37.4 but crashed with 0.38.0. Happens both on Linux an Windows. Crash message on Linux:

#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0x7fff639d7840#0 0x7f9056018e19 <unknown>

Please advice if I can help you with more info.

How to reproduce

Unclear

[ffanny]

I tried with the latest v0.38.0 and there is no error. Could you please provide your demo for reproducing? And crash dump is helpful.

[julijane]

Right now I can not provide a demo. This is a confidential application and I would need to find the part where it crashes (it does not crash right at the beginning but at some operation late ron). I will see what I can come up with. Here is a excerpt from the crash dump:

Crash reason:  SIGILL / ILL_ILLOPN
Crash address: 0x7fb6dd2e2a72
Process uptime: not available

Thread 0 (crashed)
 0  libnw.so + 0x6797a72
    rax = 0x0000000000000000   rdx = 0x0000000000000000
    rcx = 0x0000000000000b40   rbx = 0x00007fb6d6b01840
    rsi = 0x00007fb6d6b028b0   rdi = 0x00007fb6d6b01680
    rbp = 0x00007ffc263d43d0   rsp = 0x00007ffc263d40c8
     r8 = 0x00007fb6d6b028b0    r9 = 0x00007fb6d2925d00
    r10 = 0x00007ffc263d3368   r11 = 0x0000000000000000
    r12 = 0x00007fb6d7afc30c   r13 = 0x00007ffc263d4390
    r14 = 0x0000000000000000   r15 = 0x00007fb6d7d7fda6
    rip = 0x00007fb6dd2e2a72
    Found by: given as instruction pointer in context

[rogerwang]

Is there any native module need to be rebuilt against 0.38.0? Also uploading the dmp file mentioned in the link @ffanny posted would be helpful.

[julijane]

@rogerwang Is there a way to provide the file in private? It is really a strange problem. I tried to pinpoint it but it is like kind of a heisenbug, when I try to catch it it changes behavior. Interestingly: It is a Vue.js application and it only happens in a production build which makes it quite tedious to try to catch it.

[rogerwang]

You can share the file with me via Google drive. [email protected]

On Wed, May 1, 2019, 1:16 AM Juliane Holzt [e-mail] wrote:

@rogerwang https://github.com/rogerwang Is there a way to provide the
file in private? It is really a strange problem. I tried to pinpoint it but
it is like kind of a heisenbug, when I try to catch it it changes behavior.
Interestingly: It is a Vue.js application and it only happens in a
production build which makes it quite tedious to try to catch it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nwjs/nw.js/issues/7045#issuecomment-488037063, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABIMGIIJE3KKW6KV3G35CDPTB46LANCNFSM4HIJGJLA
.

[julijane]

@rogerwang I have shared a zip with multiple files with you.

[rogerwang]

@julijane I'm analyzing your dmp file and trying to get what happened there. Are you using compiled JS binary in your application?

[julijane]

@rogerwang I'm using nwjc and evalNwBin, yes. In production builds. When it has to do with that, it would explain why it does not happen in development when serving uncompiled JS through webpack-server.

[rogerwang]

Does it crash when you load the binary, or the function in the binary is called? Or, does it work well if you don't use compiled binary? It should be helpful to isolate the cause and write a reproduce case with this information.

[rogerwang]

Also please make sure you have recompiled the binary as it's not compatible between versions.

[zkrige]

crash.dmp.zip

I am having same issue. I have compiled the binary with 0.38.2, but as soon as I call any function in the binary, it crashes the app. This is on macos, and is happening for debug builds.

[GHLover]

same issue here

[julijane]

@rogerwang Can you please have another look at this? Someone else provided Crash Dumps too and a third person has now stated to be affected.

[rogerwang]

Sure. Since we have located the cause to be nwjc/evalNWBin, could anyone write a case with the js file you compile and the function being called? Please send it to [email protected] in private. Thanks.

[julijane]

@rogerwang The thing is, just using evalNWBin alone does not seem to be the problem. At least in my case it does not crash immediately after loading the binary, only after some execution time. My prior tests seem to indicate that this might not be related to any specific action in the code at all because when I comment out code where it seems to crash it simply crashed elsewhere and it does not appear to be coupled to a function call. I would suspect corrupted data structures which lead to some invalid pointers or something.

[rogerwang]

I think it is fine not crashing immediately. The case would still help me reproducing it here.

[Mann90]

be7ecc5a-9fdb-43e2-88bb-84eaad3651a2.dmp.zip

Here is another dump file.

[julijane]

@rogerwang Unfortunately I was not able yet to come up with a example demonstrating the problem. It happens in my "big" application but that one I can't provide. Maybe one of the other reporters can provide an example but I would guess that people who use evalNwBin all only have code they can't give out.

[GHLover]

I also experience. Unfortunately, my employer will not let me give the code because it is a big app we use. I am having difficulties finding a minimum test case not utilizing my employers code.

Like @julijane stated, it does not appear to be a specific bad code issue. If it errors on X bad spot of code and that spot is removed, then it will start to error on another.

In order to find a test case I wonder if anyone knows of some open source nwjs apps? Maybe they can be compiled and see if the error gets hit and then it would provide a test case.

[theDevelopper]

@rogerwang does the "How to reproduce" instructions from this ticket -- which seems similar, if not identical -- help you?
https://github.com/nwjs/nw.js/issues/7055

[julijane]

@rogerwang I have shared a zip on Google Drive with you. It contains a "minimal" application which crashes. I was not able to come up with a "plain" JS example, so this contains a index.js packed by Webpack from a Vue + Vuetify application. Also a index.bin is included, but that one is for 0.38.1 on Linux, so you likely need to recompile it. Then you can start the application, watch the counter go up to 500 and then it crashes.

Remarks:

• The 500 is not a magic number, it is just a number of "tasks to process" I set. I can lower the number to a point and it still crashes. Only when I go "too low", it stops crashing.
• What the code does: It schedules a number of "tasks" and then a repeated function call (through setInterval) does one task after the other. The task just does some data shifting around and adds (empty) keys to a object. At the end some condition is met which results in DOM manipulation (show previously hidden elements) and this appears to be when it crashes.
• It appears that some complexity is needed, both with the data manipulation and with the DOM tree. For example I use a UI library on top of VueJS here and elements of that for a "grid view" and if I use plain "div" instead, it will not crash.
• For reference I have added a "App.vue" file which is a VueJs "single file component" and the main code of my test application, so you can see what basically happens. Of course you can not build from just this file so this is only for reference. It should be noted that this code in App.vue is ALL needed to get the crash. If I only remove a little bit more it stops crashing, e.g. when I remove something from the DOM template or when I remove the code which first adds a element to the "running" array and then afterwards filters it out again.

I really hopes this helps you fix the problem as it appears lots of people are affected. To me it still appears to be some data corruption which is acknowledged by the fact that I have to do certain data manipulations and a certain minimum amount of it to provoke the crash. As speculated before also after this manipulation some DOM manipulation appears to be necessary.

[julijane]

@rogerwang In addition to my previous comment, I have shared one more zip file with you. This one contains a complete application. You can yarn install, yarn build and then take dist/js/index.js, compile it with nwjc and put it into the nw-application provided before and it will crash.

Noteworthy: Again this seems to be the bare minimum necessary. For example if I remove the import and use of "store" in main.js it stops crashing, even though this is not used in the actual code. Or maybe even more interestingly, if in src/vue-plugins/vuetify.styl I remove the second of the three imports, it stops crashing as well.

Hope this helps furthermore.

[rogerwang]

I can reproduce the bug with the sample. Thanks!

Before I fix it, you can use this workaround: add --js-flags=--no-flush-bytecode to the command line, or add --no-flush-bytecode to the js-flags field in manifest.

[julijane]

Great that we can finally tackle this bug. :muscle: Sounds like a fun bug now :smiley: so V8 flushes out the bytecode and then there is no source code to compile again, yes? I see that bytecode flushing was introduced with Chrome 74, so it makes sense :)

[rogerwang]

Yes, you are right. Now this is fixed in git and will be available in the next nightly build.

[julijane]

@rogerwang Awesome, thank you. I would guess this also closes #7055.