massimocandela / geofeed-finder

Utility to find geofeed files linked from rpsl.
BSD 3-Clause "New" or "Revised" License
76 stars 7 forks source link

When running the macos binary it always end throwing a Zlib Error #15

Closed aalmenar closed 1 year ago

aalmenar commented 2 years ago

When executing the macos binary always produces this output:

./geofeed-finder-macos-x64 -i ripe -o ripe.csv [ripe] Using cached whois data [ripe] Parsing whois data: inetnum,inet6num Error: unexpected end of file at Zlib.zlibOnError [as onerror] (zlib.js:187:17) { errno: -5, code: 'Z_BUF_ERROR' } ERROR: Delete the cache file .cache/ripe/ripe.db.gz Error: unexpected end of file at Zlib.zlibOnError [as onerror] (zlib.js:187:17) { errno: -5, code: 'Z_BUF_ERROR' } ERROR: Delete the cache file .cache/ripe/ripe.db.gz

massimocandela commented 2 years ago

The cache is corrupted, the solution is in the message:

ERROR: Delete the cache file .cache/ripe/ripe.db.gz

tallytarik commented 1 year ago

I'm getting the same error consistently on macOS. It only happens with the ripe data.

From a clean slate (no cache), it does not throw an error, but it doesn't produce a CSV. Then if I try again, it throws the Zlib error. There is nothing in the error log.

Do you know how the cache could be getting corrupted?

massimocandela commented 1 year ago

From a clean slate (no cache), it does not throw an error, but it doesn't produce a CSV.

This is weird, the process should exit with some success or error state. It may take long, but it should always exit with some message.

The only case that I can think of for the process to exit without any message is if the OS kills it for using too much memory. But it is strange for this software.

Are you sure the process exists and not just stuck? the connection is stable? the process has write permissions? enough memory on the machine?

Then if I try again, it throws the Zlib error. Do you know how the cache could be getting corrupted?

Probably the process didn't finish to download the whois dump. The ripe dump is quite large as a file.

tallytarik commented 1 year ago

I thought it was strange too! Here's an example: (everything except ripe is in cache)

➜  ./geofeed-finder-macos-x64 -o "result.csv"
[ripe] Downloading whois data
[afrinic] Using cached whois data
[apnic] Using cached whois data
[afrinic] Parsing whois data: inetnum,inet6num
[apnic] Parsing whois data
[arin] Using cached whois data: inetnum
[lacnic-rir] Using cached whois data
[lacnic-rir] Parsing whois data: inetnum
[arin] Using cached whois data: inet6num
[lacnic-rir] Using cached whois data
[lacnic-rir] Parsing whois data: inet6num
➜  echo $?
0

The process exits cleanly without an error message after about 20 seconds. It uses about ~160 MB of memory so shouldn't be killed by the OS.

The broken ripe file ends up being between 500 KB and 10 MB - so I agree I think it's just failing to download. I don't have any other issues with my connection, though.

I tried adding a long download timeout with -d 1800 but the same thing happens and the process exits well before the timeout.

massimocandela commented 1 year ago

are you able to download it in the command line with wget ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz? Are you using the binary or the source code?

wkumari commented 1 year ago

Just for giggles / as an additional data-point: I just fetched the latest release (1.6.6) binary for OSX, and ran it under macOS Ventura on an M1 Macbook. (the sha1sum for the binary is: 69ac83d16d9e1ababb6a9a45835b4abdb50d481a)

This ran fine for me (other than logging a bunch of

Cannot retrieve 199.182.160.0 ECONNRESET
Cannot retrieve 199.182.132.0 ECONNRESET
Cannot retrieve 199.182.136.0 ECONNRESET
...

:-) ) and mine peaked at ~500MB of RAM.

The .cache/ripe/ripe.db.gz file I end up with is 348MB.

tallytarik commented 1 year ago

Are you using the binary or the source code?

The last few tests have been using the binary but I've tried both.

are you able to download it in the command line with wget ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz?

Yep, that downloaded fine! Thanks - that's nice as a workaround for now.

I just fetched the latest release (1.6.6) binary for OSX, and ran it under macOS Ventura on an M1 Macbook.

That's my setup too, so I assume it's something on my end - just odd that the process seems to die with no error message.

massimocandela commented 1 year ago

I just fetched the latest release (1.6.6) binary for OSX, and ran it under macOS Ventura on an M1 Macbook.

That's my setup too, so I assume it's something on my end - just odd that the process seems to die with no error message.

I never tested this on an M1 actually. I don't have access to one, but if you are available we could do a couple of experiments. To start with, could you confirm that you get the same error if you run directly the source? What node version?

tallytarik commented 1 year ago

Sorry for the trouble - I can't reproduce it anymore. From a clean slate, both methods (binary and source) seem to work fine now. I can only guess that there was something killing the connection but honestly have no idea! :(

massimocandela commented 1 year ago

ok, then I'm going to close this.