Solaris 11: libmaxminddb not able to return latitude/longitude

[tkuenster]

'mmdblookup -i 72.229.28.185
"location":
{
"latitude":
0.000000
"longitude":
0.000000
"metro_code":
501
"time_zone":
"America/New_York" <utf8_string>
}

On linux, the same database does return lat/lon.

Another clue - make check gives some errors data_entry_list_t:
not ok 25 - double value was approximately 42.123456
Failed test 'double value was approximately 42.123456'
at maxminddb_test_helper.c line 239.
got 0.000000 but expected 42.123456 (diff = 42.123456)
ok 26 - found a map key
ok 27 - 'float' key's value is a float
not ok 28 - float value was approximately 1.1

data_types_t fails with similar issues:
not ok 84 - double value was approximately 42.123456
Failed test 'double value was approximately 42.123456'
at maxminddb_test_helper.c line 239.
got -87750184517491777524722039008539763058909340248586710645163828237927168013861995082144228853051998053752430466495949184291917310566362668094376567441251470065827607880193526468881177217420597114227413315941419592173074085574369360097342313439831655682505571750611965220873252074818033024057211773727539200.000000 but expected 42.123456 (diff = 87750184517491777524722039008539763058909340248586710645163828237927168013861995082144228853051998053752430466495949184291917310566362668094376567441251470065827607880193526468881177217420597114227413315941419592173074085574369360097342313439831655682505571750611965220873252074818033024057211773727539200.000000)
ok 85 - no error from call to MMDB_vget_value - float field for ::4.5.6.7 - mmap mode
ok 86 - got the expected data type - float field for ::4.5.6.7 - mmap mode
not ok 87 - float value was approximately 1.1
Failed test 'float value was approximately 1.1'
at maxminddb_test_helper.c line 249.
got -NaN but expected 1.1 (diff = NaN)

I wish I had some c skills to fix this - I'm assuming it's an issue with some library returning some floats or doubles in a way that maxmind doesn't like on the Solaris OS.

I have a java app on Solaris that is using the java api that does not experience this issue.

Any ideas?'

[oschwald]

What is your exact hardware? This has been tested with Solaris on x86, but I suspect that this is an endianness issue. The likely culprit is here. It is pretty hard for us to confirm or test this without access to similar hardware.

[tkuenster]

Sounds about right.
SunOS zpwscmr1 5.11 11.2 sun4v sparc sun4v

I made the edit to the two lines that check little endian to != and voila - after make, the lat/lon come through as expected.

I guess that means that sparc/solaris is erroneously reporting it's endian status.

[oschwald]

Thanks for trying it out without the check. Our detection is likely broken on your compiler. What compiler are you using?

[tkuenster]

gcc version 4.5.2 (GCC) and also tried gcc version 3.4.3 (csl-sol210-3_4-20050802) (from /usr/sfw/bin)

[rleir]

When writing to the DB, pass all 32 bit data through htonl(). On a big-endian, this is a NOP. This function is optimized well (as I recall), and might be a macro. There is no need to check endian-ness explicitly in Maxmind code.

When reading from the DB, pass all 32 bit data through ntohl(). On a big-endian, this is a NOP again.

#include <arpa/inet.h>
uint32_t htonl(uint32_t hostlong);
uint32_t ntohl(uint32_t netlong);

http://stackoverflow.com/questions/3173648/what-should-i-include-to-use-htonl

For 64 bit data it is a bit more complicated:
http://stackoverflow.com/questions/3022552/is-there-any-standard-htonl-like-function-for-64-bits-integers-in-c

[autarch]

Can you try building the code in https://github.com/maxmind/libmaxminddb/tree/autarch/fix-endianness-check to see if this fixes the problem for you?

You can build from the Git repo with the following commands:

./bootstrap
./configure
./make check

Note that you'll need autotools installed for the bootstrap step.

[oschwald]

We believe this is fixed in master. Please let us know if this is not the case.