() nil exception

Question

() nil exception

Closed this issue 7 years ago · 32 comments

I am looking for some guidance. I have been using the exceptional(!)-php interface for a few months now and enjoying it, but I am getting exceptions reported at get exceptional.com frequently that look like (screenshot sorta from get exceptional.com):

BACK TO OPEN EXCEPTIONS

() nil

11 hours ago
2 months old
Number of exceptions: 2942 Number of comments:0

() nil

Occurrences

NEWER 10 of 30 OLDER
Time
07 Dec at 11:17AM
Params

{ }

Given the total lack of details I am trying to figure out how to identify whether these are...

1- My code doing something odd in throwing an exception (my suspicion but where??)
2 - The exceptional-php interface to getexceptional.com handling an exception in a strange way ...
3 - something on getexceptional.com misrepresenting my exception

As you can see I have 2942 of these at present. I get enough exceptions using this tool that merely looking for what happened at that time is leading me nowhere, and throwing an exception in exceptional-php is probably not the proper approach. How would you suggest I locate the root cause???

Thanks for a fine interface product and any help.

Answer 1 · 2011-12-09T06:49:53.000Z

Hey TJ, I'm leaning towards 2 or 3. The library should handle all types of exceptions gracefully as long as the setup files parses correctly. Can you upload a screenshot and post the link?

Answer 2 · 2011-12-09T11:29:06.000Z

I have posted a screenshot for what it is worth - no more data than I entered above. Hence why I am at a loss to locate... Let me know what else would help.

http://www.schellingpoint.com/images/screenshot_742.png

Answer 3 · 2011-12-09T18:30:43.000Z

Thanks, I'll talk with the Exceptional team and see what's going on.

Answer 4 · 2011-12-12T08:01:20.000Z

Hey TJ, I tried recreating the bug with no success. What version of PHP are you using?

One thing you could try is writing all exceptions to a log file. The best place to do that is line 85.
https://github.com/ankane/exceptional-php/blob/master/exceptional/data.php#L85

If you log the $data variable, you can see what the PHP library is sending to the server. $data includes the time of the exception, so you can try matching the times with those on getexceptional.com.

Answer 5 · 2011-12-12T12:54:35.000Z

Well - that was going to be my next option. SO I will try to get that into place ASAP. I'll let you know what I find.

On Mon, Dec 12, 11, at 3:01 AM, Andrew Kane wrote:

Hey TJ, I tried recreating the bug with no success. What version of PHP are you using?

One thing you could try is writing all exceptions to a log file. The best place to do that is line 85.
https://github.com/ankane/exceptional-php/blob/master/exceptional/data.php#L85

If you log the $data variable, you can see what the PHP library is sending to the server. $data includes the time of the exception, so you can try matching the times with those on getexceptional.com.

Reply to this email directly or view it on GitHub:
#9 (comment)

Answer 6 · 2012-01-15T07:47:01.000Z

Any update on this?

Answer 7 · 2012-01-19T17:08:06.000Z

Not ignoring your request - just have been swamped.

Am getting back to this now. I have 2 types of errors: one which is "Undefined Offset" that always references exceptional itself line 71 and that is it. And The second is the nil problem. The nil ONLY occurs on Production, so I have to be careful about that. The other happens all the time.

So I am going to make a change on test and see if I can find the undefined offset issue (appears it could be a shutdown related issue, but the offset referenced varies).

On another note I was not getting my controller sent to getexceptional.com and I stumbled over the fact that the controller AND action must both be set or you don't include them (data.php line 70). I am going to change my code to send both, but I think either or for PHP exceptions should still be sent?

Thanks again for your guidance. Responding soon.

Tim

On Sun, Jan 15, 12, at 2:47 AM, Andrew Kane wrote:

Any update on this?

Reply to this email directly or view it on GitHub:
#9 (comment)

Answer 8 · 2012-01-19T18:58:02.000Z

I added a separate issue for tracking the similar but distinct undefined offset problem I have. There is somewhat more data for that. IN the next 2 days I anticipate a production release which will add this logging into production, so I can further uncover the "nil ()" problems source. Will keep you updated. Thanks for the guidance.

Answer 9 · 2012-01-20T16:34:38.000Z

Great, I'll look into the issues this weekend.

Answer 10 · 2012-01-20T16:38:36.000Z

I was able to make the logging available to our production environment (to catch the () nil) and so far none have occurred. WIll let you know when I get a hit.

Answer 11 · 2012-01-23T06:43:46.000Z

Sounds good.

Answer 12 · 2012-03-07T13:51:23.000Z

Great NEWS!

I got my first nil exception since we have been trying to collect by capturing the array!!

I am forwarding you my exception screen (pretty empty), and the equivalent NIL exception as caught by your suggestion of capturing the array inside your API interface into a log file.

Perhaps you can when time permits take a look at it and see if you can suggest to me why it translated to a nil in getexceptional.com.

http://media.schellingpoint.com/exc/screenshot_745.png
http://media.schellingpoint.com/exc/nil.log

Thanks,

Tim

Answer 13 · 2012-03-07T15:11:13.000Z

Wanted to add that if this is the primary source exception, it would explain why it has not been occurring so frequently, because the number of times this code path is used has been significantly reduced over the last 3 months, so the opportunity for this source line to have an exception is far lass frequent.

My inference, without prejudicing your investigation, is this has something to do with the sheer size of the results parameter being posted through this interface and being passed on as part of the exception package to exceptional.com.

Answer 14 · 2012-03-19T01:23:28.000Z

Hey Tim, I was able to reproduce the error with very large parameters. I contacted the Exceptional team and will let you know when I hear back.

Answer 15 · 2012-03-21T12:30:25.000Z

Thanks. As you can imagine I cannot see how to prevent this in my own code. It seems the only place to prevent this would be to truncate in your API code or allow it all the way through the Exceptional and have them handle it properly. Either way I don't see how I can "stop" it without altering at least this API. Appreciate your interfacing with them.

Answer 16 · 2012-05-12T12:48:38.000Z

I'm having this issue as well. Has anything happened since March 21?

Answer 17 · 2012-05-23T10:54:54.000Z

I am still getting this issue myself although less frequently - but still can attribute to size of request content (a large request fails with nil result). Would like an update. WIll probably try changing the exceptional api interface to limit the request content since this seems to be the only place I can filter the error out unless it is fixed somehow downstream.

Answer 18 · 2012-05-23T12:54:38.000Z

I was able to track down that (at least in my case) it seemed to have something to do with calling json_encode() on the data before sending to Exceptional. Specifically, in cases where there was a problem with invalid unicode characters. I've been able to make it disappear by using the following line in ExceptionalData#to_json():

$data = is_string($data) ? iconv("UTF-8","UTF-8//TRANSLIT//IGNORE", $this->data) : $this->data;

Seems like a hack to me, though.

Answer 19 · 2012-06-08T02:19:02.000Z

@tjchambers Here's the bug report - http://support.exceptional.io/discussions/problems/788-ui-bug - no updates since March.

@adamthehutt $this->data should always be an associative array

Answer 20 · 2012-06-08T11:55:01.000Z

Thanks Andrew, but the bug report is private so I cannot look at it. It is not interfering with most operations so I am not desperate for a fix, but would still like one. Sometimes the one report that goes "nil" on me is a critical one (was 2 weeks ago).

On Jun 7, 2012, at 10:19 PM, Andrew Kane wrote:

@tjchambers Here's the bug report - http://support.exceptional.io/discussions/problems/788-ui-bug - no updates since March.

@adamthehutt $this->data should always be an associative array

Reply to this email directly or view it on GitHub:
#9 (comment)

Answer 21 · 2012-06-12T16:57:17.000Z

Until the bug is fixed, the only thing we can do is write a hack to limit the size of parameters. I'll be happy to look at a pull request if you'd like to take a shot at this.

Answer 22 · 2012-06-12T19:19:15.000Z

I've made the discussion public to help you guys.

Sorry for making it private.

Answer 23 · 2012-06-12T20:36:45.000Z

I think @gary-rafferty should have some thoughts on how to resolve this.

Answer 24 · 2012-06-13T19:20:47.000Z

Strange one alright. I'll take a look over the next couple of days and see what's happening.

Answer 25 · 2012-07-12T13:12:43.000Z

any updates on this? @gary-rafferty

Answer 26 · 2012-07-12T13:19:31.000Z

Sorry for the delay. I've not had much time to look into this.
The problem is simply that the data being posted is too big.
On the server-side, the size of the post data in the request exceeds the limit defined by Rack::Utils.key_space_limit.

A client side solution to this would be to truncate those huge Exceptions and keep it beneath the limit, though I've not had the time to implement the patch.

Answer 27 · 2012-07-12T13:22:52.000Z

It would be valuable to me to know what the setting of Rack::Utils.key_space_limit is. That way I could make some sort of reasonable patch in the interim.

Answer 28 · 2012-07-12T13:26:16.000Z

Sorry, forgot to include that in the comments.
As defined in https://github.com/rack/rack/blob/master/lib/rack/utils.rb#L57

The default number of bytes to allow parameter keys to take up.
This helps prevent a rogue client from flooding a Request.
self.key_space_limit = 65536

Answer 29 · 2012-07-12T13:27:10.000Z

@gary-rafferty thanks!

Answer 30 · 2012-07-12T13:28:48.000Z

@gary-rafferty Much appreciated!

Answer 31 · 2012-07-12T13:29:45.000Z

@shime @tjchambers No problem, apologies for the delay in updating the thread.

Answer 32 · 2017-10-26T08:24:22.000Z

Cleaning up issues. RIP Exceptional :(