I wrote a node program to scrape url content. Since a lot of things get thrown into and out the machine, I have a process listener for uncaughtException and just throw the error results into a log file instead of letting it kill the daemon. Going over that log file recently, I noticed something amiss. Here's an error that gets thrown frequently and the stack trace:
Stack Trace:
ReferenceError: GEL is not defined
at Object._onTimeout
(http://www.freep.com/article/20110809/ENT04/110809051/1001/news:undefined:undefined:2:25)
at Timer.callback (timers.js:83:39)
Not very informative I know. Naturally, I rgrepped my source code for GEL. Then I rgrepped all my node module dependencies (there's not that many) for GEL. Then I rgrepped node for GEL. Then I rgrepped v8 for GEL. Then I stopped and asked StackOverflow... What am I doing wrong? (I'm not doing anything too unreasonable in my code like trying to eval random strings or whatnot.)
Important: node v 0.4.9 ... think it also gets thrown on v 0.4.10
I figured out the problem. It was in fact my code's fault. The code I was debugging was using the jsdom module, which was interpreting the javascript from the web pages I was scraping. I fixed the problem I was having by improving my regex that strips out <script> tags and passed an extra features argument to my jsdom.env call:
jsdom.env({
html: myHtml,
done: myCallback,
url: url,
features : {
FetchExternalResources : [],
ProcessExternalResources : false
}
});
Related
Similar questions has been asked, I went through 'how to debug node' threads, but
those are however either old or not about the problem i got.
Problem:
I'm writing some small tools in node.js stack - and my debugging experience is quite frustrating: when an exception is thrown, in many cases I get very annoying messages like the one here:
TypeError: Bad argument
wtf? it's neither verbose or useful - no source line number, no information in which file this exception was thrown.
Question:
How do I get my console to output usefull information when exceptions/errors are thrown and console.log function has something to say. would be great to have a simple console.log call where it actually puts a line number and maybe a file name where the message happens.
in nodejs i use this function to see error stack:
process.on('uncaughtException', function(err) {
console.log(err.stack);
})
Use the --stack option to see stack traces. Such as grunt task --stack
I'm experimenting with Dart and using the new streamSpawnFunction to create a new isolate.
I'm running my code in Dartium but i've noticed that if some kind of unrecoverable error occurs in the isolate i get no error message on the console. Because breakpoints in Isolate code are not working debugging is really painful.
The old Port based Isolate spawn function (spawnFunction) has a callback function for handling errors. I wonder why this is not available with streamSpawnFunction. Is there a new way to subscribe to the error events of an Isolate?
The missing functionality of streamSpawnFunction is just an oversight. I filed http://dartbug.com/9208 and I will try to fix it next week.
I'm not sure if it is a known problem that breakpoints don't work in isolates. I will let you file a bug-report (http://dartbug.com) so the devs can ask you questions and you are kept informed on the process.
I just started trying out Derbyjs, and I already ran into a problem. I can't find any support for this error, and most likely is some dumb mistake i'm making.
I'm trying to render a view, following the example from the www.derbyjs.com documentation.
My app is as simple as this:
var app = require('derby').createApp(module);
app.get('/', function (page, model) {
page.render('home');
});
My views are composed by two files.
"index.html"
<import: src="home">
<Body:>
Default page content
"home.html"
<Body:>
Welcome to the home page
I get the following error whenever the page is rendered:
TEMPLATE ERROR
Error: Template import of 'home'... ...can't contain content
As you can see, it is a very simple example. What am I missing?
I get that error even if I have the "home.html" file empty.
Well, I got the answer from one of the developers.
It seems like there was a subtle bug in the Template Parser that probably has already been fixed.
Having a whitespace or linebreak in front of
<import: src="home">
was causing the parser to raise the error. Writing
<import: src="home"><Body:>
solved the issue.
On POSTing data to my expressjs app, this is what I am getting:
node(58287,0x7fff771ad960) malloc: *** error for object 0x7ff8a8600c58: incorrect
checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6
Any idea why?
Update:
Here is some code:
Client side:
$.ajax({
url: 'user/' + id,
type: 'POST',
dataType:'JSON',
data: JSON.stringify(data),
success: function(response){
console.log(response);
}
});
Server side:
app.post('/user/:id', function(req,res){
var id = req.params.id;
console.log(data);
});
When I use JSON.stringify on the client side, I am hitting this weird error:
node(58461,0x7fff771ad960) malloc: * error for object
0x7fa861d00e28: incorrect checksum for freed object - object was
probably modified after being freed.
* set a breakpoint in malloc_error_break to debug Abort trap: 6
When I don't use JSON.stringify on the client side, I get 'null' strings on the server side.
Any ideas on what I am doing wrong?
I experienced this same error recently. Here's the fix:
Node.js has had some bugs that cause it to install improperly from source under OS X (see e.g. issue 2061). The good news is that the packaged installer installs it correctly. So, simply uninstall Node, then head to http://nodejs.org/#download and run the Macintosh Installer.
I've reported this bug on the Node issue tracker here.
This is liable to be a bug in nodejs's internals. (Or, if expressjs has any native-code bindings, perhaps expressjs.)
There's no easy way for you to write this kind of bug yourself in JavaScript. If you can reproduce this at will, they'd probably like a bug report. Try to figure out the least amount of code that can reproduce the problem.
I just got this error today, and updating Node.js through MacPorts from 0.8.9_0 to 0.8.10_1 fixed the issue.
It doesn't seem this was specifically adressed though, as bug reports and the changelog don't indicate that (http://blog.nodejs.org/2012/09/25/node-v0-8-10-stable/).
I haven't looked into the cause of these issues (plural - there are clearly at least two bugs somewhere along the line - jquery, node, express), although a summary and workaround are as follows:
When your client side code looks like in your updated question the server obviously shouldn't crash with a malloc error (bug #1), although it is understandable that the query is mistreated, since you're telling jquery to send json and then you send a string.
bug #2 is simply null --> "null" along the pipe. This at least doesn't cause a server crash, because data types match headers (i.e. everyone think we're using json), however someone is converting nulls to strings. My baseless suspicion is that it's express/connect.
Finally, the workaround is simply to wrap your data in a way that manages to be transported, and then unwrap on the server side:
Client side:
$.post({
url: 'user/' + id,
data: {workaround: JSON.stringify(data)}, // no null strings this way
success: function(response){
console.log(response);
}
});
Server side:
app.post('/user/:id', function(req,res){
var id = req.params.id;
var data = JSON.parse(req.body.workaround); // unwrap
console.log(data);
});
If I find time, I'll investigate and try and post a bug report somewhere (it's a problem when you don't know whose fault this is...), please try do this as well.
You are are calling console.log server-side on 'data' which is not defined in the scope of your example.
If I reload my application (from the browser with the reload button) a lots of times like 50 reload/10 seconds it gives me this error:
events.js:45
throw arguments[1]; // Unhandled 'error' event
^
Error: EBADF, Bad file descriptor
This seems to me like a bandwidth error or something like that, originally I've got the error when I played with the HTML 5 Audio API, and If I loaded the audio file 10-15 times sequentially then I've got the error, but now I've discovered that I get the error without the Audio API too just by reloading the site a lots of times, also Safari gives me the error much faster than Chrome (WTF?)
I'm using Node.js 0.4.8 with express + jade and I'm also connected to a MySQL database with the db-mysql module.
I can't find any articles on the web about this topic what helps, so pleeease let me know what can cause this error because it's really confusing :(
By "reload your application" do you mean refresh your app's home page from a browser, or actually stop and restart the node.js server process? I assume the former, in which case if you can't reliably reproduce this it will be pretty tricky to debug, especially since you don't have a good stack trace to pinpoint the source. But if you use the express.js app.error hook (docs here) you'll want to log the error path from the "Bad file descriptor" error, which should hopefully clue you in to whether this is a temporary file that got deleted or what. In terms of the actual cause, we can only offer guesses since "Bad file descriptor" is a very generic low level error that basically means you are calling an operation on a file descriptor that is no longer in the correct state to handle that operation (like reading a closed file, opening a file that has been deleted, etc).
#CIRK, take a look at this: https://github.com/joyent/node/issues/1189
it's not a node problem, but a system tuning issue.
edit: or maybe it's related to this error in connect 1.4.3:
https://github.com/senchalabs/connect/issues/297
if this is your case, just try to upgrade it
This error may result from using fs to save a file whose name is a number rather than a string. File names must be strings:
Incorrect:
const fileName = 12345;
const fileContent = "The great croissant."
fs.writeFileSync(fileName, fileContent);
Correct:
fs.writeFileSync(`${fileName}`, fileContent);
Also correct:
const fileName = "12345";
fs.writeFileSync(fileName, fileContent);