Enabling debug causes segfault

[domosapien]

Using the command line node --debug=5859 file.js, my application starts fine but then crashes with a segfault as soon as a request is received. If I remove the debug parameter, the segfault goes away. The same code works on v0.12.x and v4.2.x. Using version v5.3.0.

[MylesBorins]

Not able to produce in 5.3.0

@domosapien can you make a minimal test case and share the js file?

[bnoordhuis]

Sounds like #4261 and #4322, which was fixed in 25776f3 but hasn't been released yet.

[domosapien]

I can try to pare down my code (it's a full web server implementation with clustering, so it may take a bit to get a test case that works), but I can first test the patch from the commit to see if that works. Unfortunately, I won't get to this until next week.

As a side note, sorry for not checking closed tickets; it didn't occur to me it just hadn't been released yet.

[tsabolov]

It seems that my problem is related to this one.
I get a segmentation fault when running mocha tests with the following command:

NODE_ENV=testing node_modules/.bin/mocha --debug-brk --compilers js:babel-core/register

When I run the debugger it stops on the first line of mocha. After that I set a breakpoint in one of my files and run a debugger. Once the programs hits the breakpoint, and is about to stop on it, I get a segmentation fault:

[1]    89124 segmentation fault  ./node_modules/.bin/mocha --debug-brk --compilers js:babel-core/register

I am very far away from the native application debugging, but I have tried to execute the above command using gdb as suggested in one of articles over the net. So this is what I got (maybe it will help):

$ gdb --args node -- ./node_modules/.bin/mocha --debug-brk --compilers js:babel-core/register /Users/**/test/index.js
(gdb) run
Starting program: /usr/local/bin/node -- ./node_modules/.bin/mocha --debug-brk --compilers js:babel-core/register /Users/**/test/index.js
Debugger listening on port 5858


  **
[New Thread 0x1413 of process 89841]
[New Thread 0x1503 of process 89841]
[New Thread 0x1603 of process 89841]
[New Thread 0x1703 of process 89841]

Program received signal SIGSEGV, Segmentation fault.
0x00007fff8a84d9fe in __kill () from /usr/lib/system/libsystem_kernel.dylib
(gdb) bt
#0  0x00007fff8a84d9fe in __kill () from /usr/lib/system/libsystem_kernel.dylib
#1  0x0000000100632341 in uv_kill ()
#2  0x00000001005013b5 in node::Kill(v8::FunctionCallbackInfo<v8::Value> const&) ()
#3  0x00000001001576ef in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) ()
#4  0x000000010017844d in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>&) ()
#5  0x000000010017a584 in v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) ()
#6  0x00003ef20330839b in ?? ()
#7  0x00003a0ffb4eb481 in ?? ()
#8  0x00003ef2033082e1 in ?? ()
#9  0x00007fff5fbff410 in ?? ()
#10 0x00007fff5fbff480 in ?? ()
#11 0x00003ef203462665 in ?? ()
#12 0x00003a0ffb4eb481 in ?? ()
#13 0x0000000b00000000 in ?? ()
#14 0x00015ef100000000 in ?? ()
#15 0x0000001a68714759 in ?? ()
#16 0x00003a0ffb4eb481 in ?? ()
#17 0x00003a0ffb404189 in ?? ()
#18 0x00003a0ffb404189 in ?? ()
#19 0x00003d2457013301 in ?? ()
#20 0x0000001a68714539 in ?? ()
#21 0x00007fff5fbff4c0 in ?? ()
#22 0x00003ef203462260 in ?? ()
#23 0x000019e08e0c4db1 in ?? ()
#24 0x00015ef100000000 in ?? ()
#25 0x0000001a68714759 in ?? ()
#26 0x00003d2457013301 in ?? ()
#27 0x000019e08e0c5021 in ?? ()
#28 0x000019e08e0c4fe1 in ?? ()
#29 0x00007fff5fbff4f0 in ?? ()
#30 0x00003ef203308297 in ?? ()
#31 0x0000001a68714759 in ?? ()
#32 0x0000000100000000 in ?? ()
#33 0x000019e08e0c5021 in ?? ()
#34 0x0000000a00000000 in ?? ()
#35 0x00007fff5fbff540 in ?? ()
#36 0x00003ef203461f6f in ?? ()
#37 0x0000000000000000 in ?? ()

I absolutely don't know if it's possible to get files/methods instead of those „??“-s.

[strugee]

I've also run into this issue. I've been able to reproduce in 5.3.0 with the following testcase:

var express = require('express');
var bodyParser = require('body-parser');
var app = express();

app.use(bodyParser.json());

app.post('/moment', function(req, res, params) {
    console.log(req.body);
    debugger;
});

var http = require('http');

app.set('port', 3000);

var server = http.createServer(app);

server.listen(3000);

Obviously you should npm install express body-parser beforehand.

I also built Node.js@abe8a344a5c00d25dd8a7b4a77085a2c29a5c0c6, with debug bindings. I wasn't able to reproduce the crash, so it sounds like #4382 (comment) is correct about this being fixed.

[domosapien]

Verified 5.4.0 fixes my issue.

[domosapien]

Possible regression, I'm now getting this bug after upgrading from 4.2.3 to 4.2.6.

[MylesBorins]

@domosapien the commit that fixed this on v5 25776f3 has been backported to v4-staging. It should make it into a release in the next 2 weeks

[domosapien]

Understood, thanks.

[javascriptui]

Looks like it didn't make the cut for the 4.3.0 release.

Any news on when this might drop. This is pretty critical to back port as due to #3875 debugging with WebStorm is not really usable in 5.x can take 5 minutes due to a v8 issue regression that's awaiting to be fixed. And the 4.x release just segfault's due to this issue.

[bnoordhuis]

@javascriptui 4.3.0 was a security fix-only release. This commit is tagged for the next v4.x release which is scheduled for next week, if I'm not mistaken.

[rainabba]

Admittedly, I'm not up to speed on the release schedule, but loosing the ability to debug software natively seems like a VERY good reason to drop EVERYTHING, fix it and release an update.

When is the fix expected? Can anyone confirm the last version that didn't suffer this on 4.x?

[MylesBorins]

This just landed in 4.3.1

[rainabba]

Thanks for the note. Not sure when I would have even noticed 4.3.1 was out so it's much appreciated. Anyone have a recommendation for keeping track of releases in the LTS track?

[MylesBorins]

How would you like to be notified of a new release?

[bnoordhuis]

@rainabba https://nodejs.org/en/feed/releases.xml

[bnoordhuis]

Also:

loosing the ability to debug software natively seems like a VERY good reason to drop EVERYTHING, fix it and release an update.

Every bug is critical to someone. If we'd follow your suggestion, we'd be in continuous panic mode.

[rainabba]

Thanks for the feed. Exactly what I needed. Btw, I swear I'm not that lazy, but I will admit to working through periods where I should clearly be giving my brain a break; so I don't forget how to google "feed about node releases" :)

As for your take on bugs; generally I would agree, but node is a software platform and as such, needs a debugger for anyone to productively develop on it. All the other "bugs" are going to be largely dependant on a working de-_bug_ger (hence the self-explanatory name) so I don't see how you can minimize a broken debugger or try to act as if that's just like every other bug. Yes, every bug is critical to someone, but some bugs are critical to a LOT more people.

[MylesBorins]

@rainabba I think you might be surprised at the number of people who use the node debugger as their primary way to solve problems in an application.

All things aside. This is fixed for you now right?

[rainabba]

@thealphanerd I doubt that considering this issue alone (and how little activity) if nothing else, but my point is the criticality, not frequency. When a debugger is needed, it's NEEDED. The whole reasons we're having this conversation is because I ended up in a bad spot due to a single promise that wasn't handing errors properly and without the debugger to step through code, I had NO way of knowing so I literally had to tear an app down and build it back up until I could identify the chunk of code causing the bad behavior. To make matters work, it was a nearly top-level promise (for lab testing) which I overlooked time and again while focusing on the code I THOUGHT was responsible.

With a debugger, I could have stepped through code with a very different perspective and I'd like to think I'd have found it almost immediately. I can't confidently say since I didn't have that tool to work with, but having been writing code since '92 (to include Assembly in DOS3-6 and Borland C) and professionally since 2001, my instincts are pretty decent and that's what they tell me. Then again, I know how to use a debugger so maybe the value I place on them is higher and I am in the vast minority. That is possible and would surprise me.

Yes, 4.3.1 did fully resolve the issue.

[MylesBorins]

@rainabba glad it is fixed!

[alvinlin123]

I too was affected by this issue. While I love the speed the bug was fixed, but I have to agree with @rainabba that losing the ability to debug is very critical, lots of developers productivity will drop as result of not being able to debug. I think no one would like to work with a "language" where debug is not possible.

While I understand it takes time to fix this bugs, I think the Nodejs owners can do better communicating with the community. When I encountered this bug I googled and found this thread, which made me realize previous versions of Nodejs will have debugger issue. What I did was rolling back my Nodejs version one by one until I found the version that worked (which was 4.2.3). It would have been much nicer if it was made clear (in this thread and Nodejs website) that downgrading to 4.2.3 was a workaround.

Again, I am impressed by how fast Nodejs owners fixed this bug (I can from Java lol), kudos to you guys.

[bnoordhuis]

I think the Nodejs owners can do better communicating with the community.

We used to have a 'Known issues' section in the release notes. You would expect that to reduce the number of duplicate bug reports, wouldn't you? Well, guess again.

It's easy saying we should communicate better but I challenge you to come up with concrete proposals for improvement when even an all-out media offensive will never reach more than a fraction of the user base.

[rainabba]

@bnoordhuis Very true, but for those who don't care to hear, there's no room to complain. I'll be watching (https://nodejs.org/en/feed/releases.xml)[this] like a hawk now. Releases is very helpful, but i'd love to see a LTSAlerts type feed. Then document that in a prominent place (like is done with "Important security releases, please update now!" at https://nodejs.org/en/. That should immediately ensure that the people who need to know (those who keep updated) can't miss it and if you get a mass of users, they will ensure that the majority of the rest [who care] find out.

[alvinlin123]

@bnoordhuis what I mean by communicate better is not about making any single user is Nodejs to be aware of every single know issue. I am more referring to a poll model than a push model. For those who care enough to search through Git/Google/Nodejs website should have found that a rolling back to v4.2.3 will make debugger work again.

Yes, anything you do is not likely to reduce number of duplicate issue, but the least we can do is to manage the duplicate issue by referring them to the so-called "known issue & workaround" place, be it the Nodejs website or git issue. If today in this thread, there is a single line of comment saying that "4.2.3 is the version that debugger still works" I would call this better communication already.

All I'm saying is this, I don't mind trial and error through older Nodejs versions to find the one where debugger still works, but it would have been better if it was already documented in this thread.

[rainabba]

The issue I have with Google is that there are so many factors in the results (like popularity) that it's not great for real-time data unless the data is consistent (weather, movies, scores, etc). I really do try with Github issues too, but that's so unoptimized that EVERY search has to start with eliminating "is:open" since issues can be closed, but resolutions not deployed and sometimes even a closed issue must be read through to find the solution. That's just to show how inefficient it is. I think for more timely issues that affect a lot of people something more needs to be maintained to keep everyone productive. Keep in mind that the more productive a platform is, the more people will adopt and that leads to more help developing/maintaining it so efforts to keep it moving in the right direction should show an ROI. Anyhow. I'm just rambling now; after spending the last 14 hours crushing the AWS Elastic Transcoder API so I'm going to get some rest.

[MylesBorins]

@alvinlin123 @rainabba I made an issue to discuss improving the way we inform the community about breakages --> nodejs/NG#31

[rainabba]

Thanks for hearing me out and considering the issue.