Skip to content

received SIGSEGV for address: 0x3a8 , Many times #4908

Closed
Closed
received SIGSEGV for address: 0x3a8 , Many times#4908

Description

@efi789
efi789
opened on Jan 27, 2016

in node v5.5

PID 49877 received SIGSEGV for address: 0x3a8
/home/ubuntu/workspace/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x1b43)[0x7fc078498b43]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7fc07ccee340]
node(_ZN4node8debugger5Agent14MessageHandlerERKN2v85Debug7MessageE+0x41)[0xe06371]
node(_ZN2v88internal5Debug20NotifyMessageHandlerENS_10DebugEventENS0_6HandleINS0_8JSObjectEEES5_b+0x6e4)[0xa53dd4]
node(_ZN2v88internal5Debug17ProcessDebugEventENS_10DebugEventENS0_6HandleINS0_8JSObjectEEEb+0x9b)[0xa5630b]
node(_ZN2v88internal5Debug12OnDebugBreakENS0_6HandleINS0_6ObjectEEEb+0xaa)[0xa5642a]
node(_ZN2v88internal5Debug20ProcessDebugMessagesEb+0xf0)[0xa56580]
node[0xe1f505]
node[0xfd7cd6]
node[0xfd7d93]
node(uv__io_poll+0x3d5)[0xfe7505]
node(uv_run+0x156)[0xfd8876]
node(_ZN4node5StartEiPPc+0x440)[0xe241a0]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fc07c93aec5]
node[0x73054d]

app.js

const express = require('express');
const app = express();
const generator = require('./pointers/getPointers.js');
app.use(express.bodyParser());

// debug ========
const SegfaultHandler = require('segfault-handler');
SegfaultHandler.registerHandler("crash.log");
// debug ========



app.get('/', (req, res) => {
  res.send(404);
});

app.get('/pointCount', (req, res) => {
  res.sendfile(__dirname + '/pointers/index.html');
});

app.post('/ajax/getAnalysisText', ( req , res) => {
'use strict';
    const sectionText = req.body.sectionText;
    if(!sectionText) {
        return res.status(404).send('nating text');
    } else {
        generator.getFullObj( sectionText, res );
    }
});


const server = app.listen(process.env.PORT, () => {
  const host = server.address().address;
  const port = server.address().port;
  console.log('Example app listening at http://%s:%s ', host, port);
  console.log('*** Ready ***');
});

app.use(express.static(__dirname + '/nakdan'));

getPointers.js

const levelup = require('levelup');
const db = levelup('./newdb');

const async = require('async');

happens even when debug mode is off

Activity

  1. bnoordhuis commented on Jan 27, 2016

    @bnoordhuis
    bnoordhuis
    on Jan 27, 2016
    Member

    Do you have a test case that doesn't depend on non-core modules? We don't as a rule accept issues that use third-party modules.

  2. bnoordhuis
    added
    unconfirmed
    on Jan 27, 2016

  3. NuSkooler commented on Jan 29, 2016

    @NuSkooler
    NuSkooler
    on Jan 29, 2016

    I too have been getting a SIGSEGV in recent versions of Node. From what I've observed, this seems to only happen when the debugger is attached. My stack trace seems similar:

    PID 62009 received SIGSEGV for address: 0x3a8
/home/nuskooler/dev/enigma-bbs/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x1af4)[0x7f4ee42d2af4]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f4ee70af340]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node(_ZN4node8debugger5Agent14MessageHandlerERKN2v85Debug7MessageE+0x41)[0xddf051]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node(_ZN2v88internal5Debug20NotifyMessageHandlerENS_10DebugEventENS0_6HandleINS0_8JSObjectEEES5_b+0x7d0)[0xa3a550]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node(_ZN2v88internal5Debug17ProcessDebugEventENS_10DebugEventENS0_6HandleINS0_8JSObjectEEEb+0x93)[0xa3ab43]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node(_ZN2v88internal5Debug14OnAfterCompileENS0_6HandleINS0_6ScriptEEE+0x334)[0xa3c454]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node[0xa1a7d8]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node(_ZN2v88internal8Compiler13CompileScriptENS0_6HandleINS0_6StringEEENS2_INS0_6ObjectEEEiiNS_19ScriptOriginOptionsES6_NS2_INS0_7ContextEEEPNS_9ExtensionEPPNS0_10ScriptDataENS_14ScriptCompiler14CompileOptionsENS0_11NativesFlagEb+0x4ce)[0xa1dbae]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node(_ZN2v814ScriptCompiler22CompileUnboundInternalEPNS_7IsolateEPNS0_6SourceENS0_14CompileOptionsEb+0x1ef)[0x8dcf6f]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node(_ZN2v814ScriptCompiler14CompileUnboundEPNS_7IsolateEPNS0_6SourceENS0_14CompileOptionsE+0xb)[0x8dd13b]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node(_ZN4node16ContextifyScript3NewERKN2v820FunctionCallbackInfoINS1_5ValueEEE+0x5b4)[0xe0b2c4]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node(_ZN2v88internal25FunctionCallbackArguments4CallEPFvRKNS_20FunctionCallbackInfoINS_5ValueEEEE+0x92)[0x904ba2]
/home/nuskooler/.nvm/versions/node/v4.2.6/bin/node[0x92e3b2]
[0x13330010963b]

    Unfortunately I'm only seeing this in a fairly large project (no minimal example). Of perhaps interesting note: I have traced this down to require: My project treats some .js modules as "plugins" and require's them dynamically. This has been working for months in version 0.12.x, but when I moved to 4.2.5+ periodically require on one of these results in the crash. The crash is not specific to a particular .js being require'd.

    I understand the basis for a rule to not accept issues that involve non-core modules, but in this case I'm not sure how I can provide such a thing.

  4. NuSkooler commented on Jan 29, 2016

    @NuSkooler
    NuSkooler
    on Jan 29, 2016

    Update: Here is a stack trace from gdb without involving segfault-handler:

    #0  0x0000000000ddf051 in node::debugger::Agent::MessageHandler(v8::Debug::Message const&) ()
#1  0x0000000000a3a550 in v8::internal::Debug::NotifyMessageHandler(v8::DebugEvent, v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::JSObject>, bool) ()
#2  0x0000000000a3ab43 in v8::internal::Debug::ProcessDebugEvent(v8::DebugEvent, v8::internal::Handle<v8::internal::JSObject>, bool) ()
#3  0x0000000000a3c454 in v8::internal::Debug::OnAfterCompile(v8::internal::Handle<v8::internal::Script>) ()
#4  0x0000000000a1a7d8 in v8::internal::CompileToplevel(v8::internal::CompilationInfo*) ()
#5  0x0000000000a1dbae in v8::internal::Compiler::CompileScript(v8::internal::Handle<v8::internal::String>, v8::internal::Handle<v8::internal::Object>, int, int, v8::ScriptOriginOptions, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Context>, v8::Extension*, v8::internal::ScriptData**, v8::ScriptCompiler::CompileOptions, v8::internal::NativesFlag, bool) ()
#6  0x00000000008dcf6f in v8::ScriptCompiler::CompileUnboundInternal(v8::Isolate*, v8::ScriptCompiler::Source*, v8::ScriptCompiler::CompileOptions, bool) ()
#7  0x00000000008dd13b in v8::ScriptCompiler::CompileUnbound(v8::Isolate*, v8::ScriptCompiler::Source*, v8::ScriptCompiler::CompileOptions) ()
#8  0x0000000000e0b2c4 in node::ContextifyScript::New(v8::FunctionCallbackInfo<v8::Value> const&) ()
#9  0x0000000000904ba2 in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) ()
#10 0x000000000092e3b2 in v8::internal::Builtin_HandleApiCallConstruct(int, v8::internal::Object**, v8::internal::Isolate*) ()
#11 0x00001faaa980963b in ?? ()
#12 0x00002fc24ac153c1 in ?? ()
#13 0x00001faaa9809581 in ?? ()
#14 0x00007fff62dee6c0 in ?? ()

  5. bnoordhuis commented on Jan 29, 2016

    @bnoordhuis
    bnoordhuis
    on Jan 29, 2016
    Member

    Can you check if the nightly build works for you? The stack trace looks suspiciously like the bug that was fixed in #4328.

  6. NuSkooler commented on Jan 30, 2016

    @NuSkooler
    NuSkooler
    on Jan 30, 2016

    Can you check if the nightly build works for you? The stack trace looks suspiciously like the bug that was fixed in #4328.

    I'm certainly willing to do this, but I admit I'm not sure how. I downloaded the nightly build you linked, unzipped it to a "node_nightly" directly and added that to my path. This gave me the expected version, but npm install (to rebuild modules with this new version) fails all over.

    EDIT: npm install failures seem to be due to node-gyp attempting to use a URL that doesn't exist for header packages. Not sure how to get around this.

  7. bnoordhuis commented on Feb 3, 2016

    @bnoordhuis
    bnoordhuis
    on Feb 3, 2016
    Member

    @NuSkooler If you download the source tarball as well, you can point npm / node-gyp there with the --nodedir=/path/to/sources switch.

  8. NuSkooler commented on Feb 4, 2016

    @NuSkooler
    NuSkooler
    on Feb 4, 2016

    @bnoordhuis Thanks, that's what I needed! As for the actual issue, it appears to be fixed in the nightly build you linked.

    Also, if it helps any, the problem does not occur for me in 4.2.0 either.

  9. bnoordhuis
    added
    debugger
    and removed
    unconfirmed
    on Feb 4, 2016

  10. bnoordhuis commented on Feb 4, 2016

    @bnoordhuis
    bnoordhuis
    on Feb 4, 2016
    Member

    Good to know, thanks for following up. The fix is scheduled for the next LTS release. I'll close the issue.

  11. bnoordhuis
    closed this as completedon Feb 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions