A strange learning path bug... fixed

See update below for the fix

I'm trying to get my head around a super-tricky bug since last Friday. Basically, the bug happens only on one portal and with a specific learning path imported by Oogie. The bug appears due to a loss of session before the generation of the table of contents. Something like this appears:

Fatal error: Call to a member function get_theme() on a non-object in /var/www/yourportal/main/newscorm/lp_toc.php on line 39

The bug is not in the Oogie conversion (no strange characters) as the same content works on another portal on the same server. The bug is not a PHP configuration problem either, as again, another portal on the same server, with the same PHP configuration, works perfectly. The problem seems to reside in the time the newscorm tool needs to generate some of the frames. Apparently, one of the frames loads before the others, and looses the session data, but only on this portal. I'm not out of things to try out, but this one is really a painful one.

2008-07-04 Update

After a long week of interrupted searches, I realised (mostly thanks to a conversation with Arnaud) that the bug was caused by an overflow in the session size capacity. Now most of you PHP developers will think "mmmmh, is there actually a way to limit sessions file size on disk?". Well, the answer is "no", not in the predefined PHP5 options, anyway. However, there is kind of a special condition here: the portal on which this error occured had the setting configured to save the sessions inside the database, using the dokeos_main.php_session table. The thing is, inside this table, we defined the field to store the session as a "text"-type field (or blog, which is the same for MySQL 5). However, I did an enormous mistake in thinking that a "text"-type field could actually store up to 4MB. It can't. It just stores a maximum of 16KB. This size should be enough, in most situations... yes, but not in the learning path object situation. Learning paths are very large objects with a structure set to limit the number of queries made on the database. Even then, however, it coped nicely with *most* learning paths, until this 56-pages learning path appeared. Apparently, the structure was too large and went over the 16KB limit, making it unproper to serialization into the database field. So basically, turning the field to a MEDIUMTEXT field fixed the problem:

ALTER TABLE php_session CHANGE session_value session_value MEDIUMTEXT NOT NULL;

To make things clear, the problem appeared to be a loss of session, somewhere between the script where the learning path object is built and the first script using it straight from the session. Debugging the second script showed that the session was recovered (or rebuilt), but without that large element, which just couldn't be stored in the database. This made it really difficult to track down, as nothing is telling you anywhere (even with full debugging on) that the problem comes from the session size and the database field limit... Of course, this has all been fixed in the Dokeos code for the next version of Dokeos, so you don't have to worry too much about it, it will just get updated automatically.