New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON.stringify crash #203

Closed
fcarreiro opened this Issue Aug 27, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@fcarreiro

fcarreiro commented Aug 27, 2016

I would like to point you to
strongloop/strong-pm#307
since it may actually concern this subproject.

@rmg

This comment has been minimized.

Member

rmg commented Aug 27, 2016

@sam-github this has been around for a while, but I'm pretty sure #199 would resolve it since it completely removes the feature with the bug. Thoughts?

@rmg rmg self-assigned this Aug 27, 2016

@rmg rmg added the #wip label Aug 27, 2016

@fcarreiro

This comment has been minimized.

fcarreiro commented Aug 27, 2016

I'm trying to isolate this "bug", since it only happens to my code base when I move from mysql with explicit connections to connection pooling (which uses EventEmmiter in a more fundamental way). It is probably not just a Strongloop bug. However, it is proving extremely difficult to isolate. I'll let you know if I can do it.

@rmg

This comment has been minimized.

Member

rmg commented Aug 27, 2016

@fcarreiro that's actually a pretty useful clue. I'm not familiar with the mysql module code, but you seem like you might be. Maybe you can corroborate this theory:

If Connection.prototype.query receives an object as it's sql argument instead of a string, then that might throw off the probe which appears to be expecting a string. If an object is passed and intercepted there, it would propagate to the top-calls collection where it would be stored until forwarding to strong-supervisor where it would meet up with the stackrace you provided in strongloop/strong-pm#307 (comment).

@fcarreiro

This comment has been minimized.

fcarreiro commented Aug 27, 2016

I have to admit that, so far, I've only used Strongloop as a process manager. I was not aware that it was intercepting calls to the mysql code (as I'm not using it for profiling, etc.) Regarding mysql, I'm no expert at all :) but I'm trying to sort this out.

The call I'm using is actually Pool.prototype.query, for the record. I have just tried passing objects as the sql and it seems to respond ok. That is, error, but no crash in Strongloop :/

@rmg

This comment has been minimized.

Member

rmg commented Aug 28, 2016

@fcarreiro sorry, I'm not sure what I was thinking before! It couldn't be related to MySQL because those metrics don't even propagate through strong-supervisor. 😊

It is the http probe, specifically for your request handlers, that would be the origin of the mishandled data.

Do you (or your framework/middleware) do anything with your request objects to make the url property an object instead of a string? It should be pretty straight forward to inject some debugging output into your app to find out :-)

@fcarreiro

This comment has been minimized.

fcarreiro commented Aug 28, 2016

I'll check! I use express, and have many middlewares. However, it still puzzles me that I only can reproduce this error if I use mysql connection pooling! Does Strongloop do something with the errors propagated through the middlewares? Because there I am certainly using objects there (well, JSON).

@fcarreiro

This comment has been minimized.

fcarreiro commented Aug 28, 2016

@rmg Hmm, the urls seem ok, in general. One question, does Strongloop maybe save the whole req as a context or something like that? It may be nonsense but now I'm wondering if something like this could be happening: Using passportjs I deserialize some user into req.user. What I assign to user is actually the raw result from a mysql query (AFAIK, that's what people do). I think this result has some mysql metadata. It could be the case that that object contains some reference to, say, the connection. The connection is clearly (sub)process dependent and will not stringify nicely in the top calls. Moreover, the connections get invalidated more often/carry more data when using connection pooling.

It's a long shot, but maybe rings some bell.

Update: I've just returned {} in the deserialization and it still happens. It could still be some other db call in my code (related or not to req) but no success for the moment.

Update: I've checked the results of every db call (that my app does, not the imported middleware) with inspect and they don't seem to have any weird db info.

@fcarreiro

This comment has been minimized.

fcarreiro commented Aug 30, 2016

@rmg I see that you merged #204, when it makes it to a release let me know and I'll report on that ;)

@sam-github sam-github added #tbr and removed #wip labels Aug 30, 2016

@sam-github sam-github closed this Aug 30, 2016

@sam-github sam-github removed the #tbr label Aug 30, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment