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.
Related
I want to xhr some opal script, and use ruby code defined there. I tried to get it with $.getScript. But no success for me.
$.ajax({
url: 'assets/foo.js.rb',
success: function(data){
#{ClassInFooJs.new}
},
dataType: "script"
});
Moreover the script is evaled (in strange manner), I mean I can call Opal.modules["file_i_required"] from console, and it will return basically the compiled code.
BUT inside of it nothing is evaled, (no console.logs, window["foos"] = #{something}), and I can't reference anything from that file.
Any help?
You should use either require "foo" from Opal or Opal.require("foo") from JavaScript. If the load "foo" behavior is required should be noted that Opal.load("foo") is also present.
The alternative is to compile files on the server with the :requirable flag set to false but that's kinda difficult unless you compile manually. See the API docs for more info.
Calling directly Opal.modules["foo"](Opal) should be avoided as it doesn't properly update $LOADED_FEATURES and in general can change in the future.
I am trying to understand how to build my error handling system for my api.
Let's say I have a the following line in a controller method :
var age = json.info.age;
with
json = {"id":1, "name":"John", info": {"age":27, "sex":"m"}}
Let's say that the object doesn't contain an info field, I'll get the following error TypeError: Cannot read property 'info' of undefined and my server will crash.
Is there a way to make a higher level abstraction and catch all the potential errors that I could have? Or should I have a try/catch system for each of the methods of my controllers?
BEWARE OF THE CODE BELOW, IT WILL BITE YOU WHENEVER IT CAN!
Don't use the code snippet below if you do not understand its
implications, please read the whole answer.
You can use the node way for uncaught errors. Add this in your config/bootstrap.js
Updated the snippet below to add what was said in the comments, also added a warning about using a global to respond to the user.
process.on('uncaughtException', function (err) {
// Handle your errors here
// global.__current__ is added via middleware
// Be aware that this is a bad practice,
// global.__current__ being a global, can change
// without advice, so you might end responding with
// serverError() to a different request than the one
// that originated the error if this one happened async
global.__current__.res.serverError();
})
Now, can doesn't mean should. It really depends on your needs, but do not try to catch BUGS in your code, try to catch at a controller level the issues that might not happen every time but are somehow expected, like a third-party service that responded with empty data, you should handle that in your controller. The uncaughtException is mainly for logging purposes, its better to let your app crash if there is a bug. Or you can do something more complicated (that might be better IMHO), which is to stop receiving requests, respond to the error 500 (or a custom one) to user that requested the faulty endpoint, and try to complete the other requests that do not relate to that controller, then log and shutdown the server. You will need several instances of sails running to avoid zero downtime, but that is material for another question. What you asked is how to get uncaught exceptions at a higher lvl than the controllers.
I suggest you read the node guide for error handling
Also read about domains, even thought they are deprecated you can use them, but you would have to deal with them per controller action, since sails does not provide any help with that.
I hope it helps.
You can check this way if you want to:
if (object != null && object.response != null && object.response.docs != null){
//Do your stuff here with your document
}
I don't really get what is your "object" variable in the first place, so i don't know if you can check it at a different level, is it a sails parameter to your controller ?
So that's how I did it, thanks to Zagen's answer.
module.exports.bootstrap = function(cb) {
process.on('uncaughtException', function (err) {
//Handle your errors here
logger.fatal(err);
global.__current__.res.serverError();
})
cb();
};
I send a generic error 500 to the user if any uncaught exception is thrown, and I log the error to the fatal level. On that way, my server is still accessible 24/7 and I can monitor the logs at another level and trigger an alarm on a fatal error. I can then fix the exception that was thrown.
I've been using Google Translate API for a while now, without any problems.
I recently pushed my app to my new server and even if it has been working perfectly on my local server, the same source code always gives me the "Required parameter: q" as error message.
I'm using NodeJS + ExpressJS + Request to send this request. Here's my test case:
var request = require('request');
request.post({
url: "https://www.googleapis.com/language/translate/v2",
headers: {"X-HTTP-Method-Override": "GET"},
form: {
key: /* My Google API server key */,
target: "en",
q: ["Mon premier essai", "Mon second essai"]
}
}, function(error, response, data) {
if (!error && response.statusCode == 200) {
console.log("everything works fine");
} else {
console.log("something went wrong")
}
});
Running on my local machine gives me "everything works fine", and running it on my server gives me "something went wrong". Digging more into it, I get the error message mentioned above.
As you can see, I'm trying to translate in one request two sentences. It's just a test case, but I really need to use this through POST request instead of doing two GET request.
I have no idea what this is happening, and I double checked my Google settings and I can't find something wrong there.
Also, I'm having no problem using Google Places APi with this same api key on my server.
I'm stuck. Anyone has any idea what's wrong here?
Well I finally found what was wrong: the new version of RequestJS doesn't work as the old one and my server was running 2.16 when my local machine was running 2.14.
The difference is the way the array is sent. I debugged and the old version was sending
key=my_api_key&target=en&q=Mon%20premier%20essai&q=Mon%20second%20essai
When the new version is sending
key=my_api_key&target=en&q[0]=Mon%20premier%20essai&q[1]=Mon%20second%20essai
So I just added 2.14.x instead of 2.x in my package.json file for now, hopefully it will get fixed soon — or maybe it's not a bug? I don't know.
This answer is a little late but to help people out there with this problem. The problem comes from the way the querystring module converts array parameters:
https://github.com/visionmedia/node-querystring
Its function qs.stringify converts fieldnames (q in the given example) that have an array value to the format:
q[0]=..q[1]=...
This is not a bug but an intended functionality. To overcome this problem without reverting to an old version of the request module you need to manually create your post by using the body option instead of the form option. Also you will need to manually add the content-type header with this method:
var request = require('request');
request.request({
url: "https://www.googleapis.com/language/translate/v2",
headers: {
"X-HTTP-Method-Override": "GET",
'content-type':'application/x-www-form-urlencoded; charset=utf-8'
},
body:'key=xxxx&target=en&q=q=Mon%20premier%20essai&q=Mon%20second%20essai'
}, function(error, response, data) {
if (!error && response.statusCode == 200) {
console.log("everything works fine");
} else {
console.log("something went wrong")
}
});
Obviously this is not as clean but you can easily create a utility function that creates the body string from the object the way you want it to.
things that pop into my head:
jquery file version on server and local PC are not the same
file encoding issues (UTF8 on PC ascii on server?)
have you tried testing it with chrome with Developer Tools open, then check "Network Tab" and verify exactly what is being sent to Google.
For me at least, when it works on one machine and not the other, it is usually due to the first 2 options.
Good Luck!
If anyone here is familiar with the node-cloudfiles module for node.js, I could use some help in several different areas. Unfortunately, is seems the authors are nearly impossible to reach via their github repo (EDIT: nevermind, someone did reach out to me, I'll send an update when I have an answer of some sort prepared.)
I'll start with my most basic challenge: is there a way to track the progress of the upload? I have tried many things, but the object returned from the .addFile command does not seem to hold any sort of progress stats.
Here is a basic outline of what I am working with.
var readStream = fs.createReadStream(path+'.'+extension, streamopts);
var upOpts = {
headers: {
'content-type': 'video/'+extension,
'content-length': totalBytes
},
remote: CDNfilename,
stream: readStream
};
//reqStream is the object returned from the 'request' module,
//which is used by the 'cloudfiles' module.
var reqStream = cloudClient.addFile(Container.name, upOpts, function (err, uploaded) {
if (err) { console.log(err); }
});
At first I thought I could just use the .bytesWritten property connected to an interval timer, but the object is not a normal node writeStream, so there is no such property.
Charlie (the author of the module) told me that this is possible because it's using a pipe and you just check the data events from the object returned from .addFile, like so:
reqStream.on('data', function () {
/* track progress /*
});
Whenever you need to contact somebody from the nodejitsu team, join the #nodejitsu channel on IRC, they're really active.
At the time of writing this answer, there isn't really a good way to get upload progress for files being sent to cloudfiles. However, one of the nodejitsu geniuses implemented chunked uploading, which in my case, eliminates the need for progress reports. Thanks Bradley.
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
}
});