Node 0.11 segfault problems #26
Comments
|
That's the kind of thing that happens if something is overrunning one of its buffers by a few bytes and it corrupts the headers that malloc depends on. I can't think of anything that's been changed in the Android port that would cause that. Being 0.11, and (relatively) unstable, it's possible there's a bug in the generic code, but you'd expect that kind of thing to show up fairly readily on other platforms. Do you have the tombstone from the logcat? |
|
no. how to i get the tombstone? |
|
Okay. Here's the adb logcat log: D/libEGL ( 380): loaded /vendor/lib/egl/libEGL_POWERVR_SGX540_120.so |
|
And here is the tombstone. Build fingerprint: 'Android/full_maguro/maguro:4.1.2/JZO54K/6:userdebug/test-keys' backtrace: stack: memory near r5: memory near r7: memory near r8: memory near r9: memory near sl: memory near fp: memory near ip: memory near sp: code around pc: code around lr: pid: 435, tid: 436, name: SignalSender backtrace: stack: pid: 435, tid: 437, name: v8:SweeperThrea backtrace: stack: pid: 435, tid: 438, name: v8:SweeperThrea backtrace: stack: pid: 435, tid: 441, name: node backtrace: stack: |
|
Thanks. Nothing really obvious there. Can I reproduce this? |
|
It should be 100% reproducible. I've created a branch of my project with the smallest code that can reproduce it. https://github.com/joshmarinacci/aminolang/tree/segfault2 Make a /data/phonetest directory on your android device, check out the source, then run 'node build androidtest'. It will copy all of the needed files to your device. Then adb shell, cd data/phonetest, run ./runit.sh to run the app. The only interesting code is in src/node/klaatu.cpp. Essentially this code opens a GL surface, compiles a shader, allocates some memory, then swaps the buffer. Removing the shader compile or changing the amount of memory allocced will avoid the segfault or move it to a different time. It's rather non-deterministic, though it's 100% reproducible. Very strange. |
|
Note, I've included a precompiled native module, aminonative.node. If you want to recompile the native code you'll need to have an AOSP full OS build to do it. |
|
Continuing to work on this. I've reduced it to some C++ code without node hooks. I have a function called TestNative which opens a screen, loads an image, loads a shader, and draws some rects. If I call this function from node it crashes. If I call it as a regular C commandline program it's fine. Definitely something wonky with node. |
|
Can you write a standalone c program that loads your .node shared library using dlopen and calls your code that way? I'm wondering if there is some linkage/storage problem that shows up because your code is in a shared library - ie there's some global variable for example that needs to be in shared library statics. |
I'm trying to track down an issue I'm having using libpng inside of a node native addon. Whenever I read a file the next call to OpenGL crashes. I've isolated it to memory allocation. If I allocate a chunk of memory in my addon (say: 10k bytes) then later on node will segfault. If I don't allocate it then node proceeds into the gl loop just fine. Any ideas what could be causing this? Is there anything in node that might be messing with memory it's not supposed to, and my malloc triggers the issue?
The text was updated successfully, but these errors were encountered: