I was getting intermittent blank pages with my modx .9.2.1, which has been mentioned more then a few times before- usually in connection with logging. I’ve looked into the problem more closely and this is what I’ve found. If this has already been fixed in .9.5, please excuse me.
The error one sees in the php logs is "cannot modify header information - headers already sent by (document.parser.class.inc.php:472)...
However, this error is caused because it had previously thrown and printed out a mysql error:
"Execution of a query to the database failed - Duplicate entry '2147483647' for key 1"
Or something similar. This error doesn’t make it into the php error logs, or on to the page your viewing. The interesting thing is that the query in question was this:
INSERT INTO `db`.modx_log_hosts(id, data) VALUES('4033976523', 'cpe-ip.hvc.res.rr.com')
What is happening is that the number its trying to insert for ’id’ is larger than the max value for the data type of that field, so its maxing it out at that 2147483647 and finding duplicates. The field ’id’ is of type int(11) [which should really be int(10) , because there are only 10 digits]. int has a max range of -2147483648 to 2147483647, but the crc32 function (which is what generates that number, crc32($hostname); ) has a higher max range. I’ve been unable to figure out exactly what that range is, but most likely -4294967296 to 4294967295. Technically I guess they should be the same, since they say they are both 4 byte numbers, but they seem to not agree on what that means when it comes to signed integers- atleast for my server. Can anyone else confirm this?
The effect of this is pretty nasty. You get seemingly random errors only for certain hosts, visiting pages which trigger a log, and depending on which browser you are using. (ff seems to be unaffected for me, but this probably has more to do with ff showing the page as it loads, instead of waiting for it to finish like IE does). Some people will never duplicate this error because their host crc32’s to a small number.
I’ve also seen that there are a few more places in the code (in document.parser.class.inc.php) which use crc32()’s of certain variables, which are also inserted into ’int’ fields in the database. Presumable they are also effected by this bug, and probably create some pretty bazaar errors.
One way to fix this is to use a different crc32 function which returns an unsigned crc32 number, and then just change the field types on the relevant fields to be unsigned int. The other is to use the field type of ’bigint(10)’ instead of ’int(10)’- the overkill approach. Of course there are other ways as well (including turning off logging).
Hope this helps.
Keep up the good work, modx rocks.
-auz
php 4.4.2
MySQL 4.0.22
modx 0.9.2.1
litespeed 2.2-std
gentoo AMD64 2.6
☆ A M B ☆
