Skip to content
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

undefined method `slice!' for nil:NilClass #27

Closed
kenn opened this issue Apr 8, 2013 · 7 comments
Closed

undefined method `slice!' for nil:NilClass #27

kenn opened this issue Apr 8, 2013 · 7 comments

Comments

@kenn
Copy link

kenn commented Apr 8, 2013

I have this error on production:

NoMethodError: undefined method `slice!' for nil:NilClass
[GEM_ROOT]/gems/geoip-1.2.1/lib/geoip.rb:535:in `block in seek_record'
[GEM_ROOT]/gems/geoip-1.2.1/lib/geoip.rb:531:in `downto'
[GEM_ROOT]/gems/geoip-1.2.1/lib/geoip.rb:531:in `seek_record'
[GEM_ROOT]/gems/geoip-1.2.1/lib/geoip.rb:239:in `city'
[GEM_ROOT]/gems/geoip-1.2.1/lib/geoip.rb:183:in `country'

I can't reproduce the same error with the same IP, so it seems to have something to do with its internal state? Not sure.

It is with Ruby 2.0.0p0.

@cjheath
Copy link
Owner

cjheath commented Apr 8, 2013

This is commonly caused by concurrency issues. seek_record is safe, but are you sure you have a valid GeoIP instance?

@kenn
Copy link
Author

kenn commented Apr 8, 2013

Concurrency as in inter-process? We use Unicorn and not using threads, FWIW. We've been using this gem for years and haven't had any errors.

@cjheath
Copy link
Owner

cjheath commented Apr 8, 2013

Oh, wait. The slice() you mention is in the IPv6 code, which is fairly new. What database file are you using? The file contains a binary search tree, where each bit of the IP address chooses one of two pointers from a node. The search is supposed to stop when a pointer points outside the tree data section. If this termination-test fails for some path down the tree (perhaps because the data size is wrong), the next node read may return nil and cause the exception in slice!.

To debug it, you need (or I need) a copy of the database file, and the IP address which fails. We need to know what the start and end offsets are of the search tree in the file, and the offset and contents of the node which points outside the tree and hence causes the failed read.

@kenn
Copy link
Author

kenn commented Apr 8, 2013

The failing IP address was 115.80.0.109, but as I said, I can't reproduce the error, which is weird.

The database file was downloaded from http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz a while ago - on Aug 22, 2012.

@cjheath
Copy link
Owner

cjheath commented Apr 9, 2013

That file is not even an IPv6 data file, so the initialiser for GeoIP has failed to correctly read the file header and/or identify the file format version. I suspect perhaps an I/O error? How many times did the error occur?

@kenn
Copy link
Author

kenn commented Apr 9, 2013

There's no other errors - this error occurred only once.

As I said, we've been using the gem for years and haven't had any problems except this one. Here's the code we have in initializer:

class GeoIP
  DB = GeoIP.new(Rails.root.join('db/geoip/GeoLiteCity.dat'))
end

and rails console:

$ zeus console
Loading development environment (Rails 3.2.13)
[1] pry(main)> GeoIP::DB.city('166.137.186.47')
=> #<struct GeoIP::City
 request="166.137.186.47",
 ip="166.137.186.47",
 country_code2="US",
 country_code3="USA",
 country_name="United States",
 continent_code="NA",
 region_name="CA",
 city_name="Encinitas",
 postal_code="",
 latitude=33.037000000000006,
 longitude=-117.292,
 dma_code=825,
 area_code=760,
 timezone="America/Los_Angeles">

@cjheath
Copy link
Owner

cjheath commented Apr 9, 2013

Put it down to a glitch in your I/O system. If it's not re-occuring, it's not a bug that can be fixed.

@cjheath cjheath closed this as completed Apr 9, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants