Debugger that works with modx?

Quote from: Jack_hawk at Apr 13, 2010, 05:42 PM

Authors of modx’s revolution may want to check this thread
http://marc.info/?l=php-internals&m=126659498827675&w=2
and in paticular follow what the poster called "a feature documented for several years" and add a session_write_close() function call in the custom session handler:
http://marc.info/?l=php-internals&m=126659692130867&w=2
Personally I agree with Christian Seiler. This all looks like a big crap in php core because no modules do ever expect any code executed after RSHUTDOWN. Allowing such behavior will cause many troubles anyway even though there a workaround with session_write_close(). It’s just so easy to forget and nothing will warn you.
In case of modx, the following modules/functions/methods are executed after RSHUTDOWN:
modx-2.0.0-rc-1/core/model/modx/modsessionhandler.class.php (write)
modx-2.0.0-rc-1/core/xpdo/xpdo.class.php (getOption, getObject, getObjectLoader, getAncestry, loadClass,
getDebug, loadClass, getCriteria, newQuery... in total 123 functions/methods)
modx-2.0.0-rc-1/core/xpdo/om/xpdoobject.class.php (load, getSelectColumns, _loadRows, _loadInstance, in total 47 function/methods)
and so forth

Thanks for the information Jack. This looks like a big problem, at least for anyone interested in using APC with certain releases. The good news is, it works fine with APC in 5.3 as is, as well as with eAccelerator on various 5.2 releases. At least, I have no problems with it (currently running 5.3.1 with APC from MacPorts on OS X), so I question the total accuracy of this information. Yes, these problems do occur in some environments, but there must be more to it or this would be reproducible consistently, no?

Regardless of my doubts, MODx uses register_shutdown_function() to execute a method that is also a part of the modX user-space object; would calling session_write_close() at the end of the modX::postProcess() method solve this problem? Since I can’t reproduce the problem atm, I’ll have to rely on someone who can to verify.

Quote from: OpenGeek at Apr 14, 2010, 07:46 AM

MODx uses register_shutdown_function() to execute a method that is also a part of the modX user-space object; would calling session_write_close() at the end of the modX::postProcess() method solve this problem? Since I can’t reproduce the problem atm, I’ll have to rely on someone who can to verify.

For me this works for my frontend (the site I created), but not for the MODx Revolution backend.

Cheers,
Jan

Quote from: enigmatic_user at Apr 14, 2010, 08:03 AM

For me this works for my frontend (the site I created), but not for the MODx Revolution backend.

Right, the backend does not use the register_shutdown_function(). The session_write_close() would actually have to be manually added to all the possible request paths in the manager application, and thus will take a little more effort to solve.

At least, I have no problems with it (currently running 5.3.1 with APC from MacPorts on OS X), so I question the total accuracy of this information

Mine is win32/apache 2.2.11 (vc9)/php-5.3.2 (vc9) and I can easily reproduce the crashes mentioned by Jan.
The reason for the crash is clearly described by Christian Seiler in his post. What he said in the Rationale section I saw in the crash call stack and in the logs, I mean excution of functions/methods after RSHUTDOWN is called.

Although I have to say that I didn’t try his path and I didn’t try to add the session_write_close function call.
That’s the most accurate information I have.

-jack

A huge thanks to Jason/Jack/Jan for fixing/finding/describing the session_write_close bug as it pertains to modx revo running on Windows. Im now debugging in Nusphere with the rc2 fixes on IIS. Ahhhh. So much better than print statements.

Thanks all.