Login to download the latest version of Mint and your favorite Pepper, purchase additional licenses, or post in the Forum. Don't have an account? Create one!

In Partnership with Media Temple

Mint Forum

crc32 is broken on 64-bit systems

Since Google started its self-serving obfuscation of search strings a while back (guess what, Google Analytics is not affected), my referrer logs are cluttered with Google search URLs. I followed a previous forum posting’s recommendation to add google URLs to the referrers blacklist (annoying, because you have to list google.com, google.co.uk and all their country-specific domains).

This worked for a while, but since I upgraded to a 64-bit host (Joyent, running OpenIndiana, a variant of Solaris, PHP 5.4.6 and MariaDB 5.5.25), it stopped working.

After going through the source, I have determined the problem is that when Mint attempts to insert a row in mint_visit with the CRC32 checksums domain_checksum, resource_checksum and referer_checksum, in many cases, the checksum is being silently capped by MariaDB to the max allowed value of a INT(10) type, which is 2147483647.

It seems Mint is making the assumption that crc32() checksums fit within a signed int, which is true on 32-bit systems but not on 64-bit ones.

I am not sure how to proceed to fix this. I could change the column type from INT(10) to INT(10) UNSIGNED, but that would break on 32-bit systems. MySQL’s CRC32 function is specified to return an unsigned int, but PHP’s behavior is platform-dependent: http://php.net/manual/en/function.crc32.php

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 103254
Server version: 5.5.25-MariaDB-log Source distribution

This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [mint]> select * from mint_visit order by id desc limit 1\G
*************************** 1. row ***************************
               id: 340704
               dt: 1348625898
          referer: http://bashdb.sourceforge.net/pydb/pydb/lib/subsection-thread.html
 referer_checksum: 2147483647
  domain_checksum: 1308678702
 referer_is_local: 0
         resource: http://majid.info/blog/threadframe-multithreaded-stack-frame-extraction-for-python/
resource_checksum: 2147483647
   resource_title: Threadframe: multithreaded stack frame extraction for Python | Fazal Majid's low intensity weblog
     search_terms: 
 img_search_found: 0
   browser_family: Chrome
  browser_version: 21.0.1180.89
         platform: Windows
       resolution: 1366x768
    flash_version: 11
     window_width: 799
    window_height: 607
 referred_by_feed: 0
 platform_version: Unknown
1 row in set (0.00 sec)

MariaDB [mint]> select crc32('http://bashdb.sourceforge.net/pydb/pydb/lib/subsection-thread.html');
+-----------------------------------------------------------------------------+
| crc32('http://bashdb.sourceforge.net/pydb/pydb/lib/subsection-thread.html') |
+-----------------------------------------------------------------------------+
|                                                                  4233754881 |
+-----------------------------------------------------------------------------+
1 row in set (0.00 sec)

MariaDB [mint]> drop table sop;
Query OK, 0 rows affected (0.01 sec)

MariaDB [mint]> create table sop(bar int(10) unsigned);
Query OK, 0 rows affected (0.01 sec)

MariaDB [mint]> insert into sop values (4233754881);
Query OK, 1 row affected (0.00 sec)

MariaDB [mint]> select * from sop;
+------------+
| bar        |
+------------+
| 4233754881 |
+------------+
1 row in set (0.00 sec)

MariaDB [mint]>

We had this problem, too, across the board in nearly every table. The solution, as you inferred, was to change all checksum-based INT(10) field types to INT(10) UNSIGNED. YMMV, of course, but our issue started when we moved the Mint htdocs to a 64-bit server, and our DB is on the same, 64-bit server. Obviously if we still had any 32-bit servers in the mix this might not work out as well…

You must be logged in to reply. Login above or create an account