Debugger that works with modx?

Clever! but then of course, considering the source

Somebody pinch me. I think I’m dreaming.

Quote from: wowzow at Mar 18, 2010, 07:44 PM

Im currently finding that the nusphere IDE’s debugger, DBG, specifically dbg-php-5.3.dll, doesnt play nice with modx. Causes a crash of the IIS fastcgi every time I attach it to a modx process.

I’m having the same problem, see http://forum.nusphere.com/problems-with-dbg-php-5-3-dll-x86-vc6-t6895.html. On my local development server I then deactivated the custom session handling by commenting out


in /core/model/modx/modx.class.php in the function _initSession() (approximately line 2651).

Maybe someone could look into this - I have absolutely no idea why the custom session handling should crash a webserver when the debugger DLL is loaded...

Cheers,
Jan

Me too. Please post here if there’s a solution.

Hmmm, xdebug is working great now in RC1; I imagine this is a Windows specific issue with DBG and PHP 5.3.

Thanks for the tip enigmatic. I gave your solution a try but it didnt work for me. Im crashing later on in the process.

Just a S.W.A.G. (scientific wild assed guess) but it kinda sounds like you might not have read/write/alter permissions on the sessions directory?

I never got quite as far as ID’ing specific modx code that was crashing the debugger.

As of a few days ago, I fired up a trial of Zend studio 7.1 and attached it’s debugger to some modx processes --- but that was also crashing fastcgi too. So that’s two, out of two, debuggers down. Only a few more to go...

For me on IIS x64, running everything only in 32 bit mode (IIS, fastcgi, php), then trying all combinations of vc9 or vc6 builds and php versions 5.2.11, 5.2.13, 5.3.1, or 5.3.2, without exception, all crash fastcgi with the same error.

Doesnt matter if im using nusphere phped debugger (correct dbg.dll versions with each php vers, of course) or the zend debugger -- they all exit with a M.S. Global error msg of
AppName: php-cgi.exe AppVer: 5.2.10.10 ModName: php_pdo_mysql.dll ModVer: 5.2.10.10 Offset: 00002580 (appver: & modver: values vary depending on php version, of course)

and the same page returned error msg for all versions of:
<terminated, exit value: -1073741819>

Im currently scouring through all the php bugs where the pdo/mysql dll leaves mysql connections open and crashes the cgi. I was hoping to NOT have to debug these debuggers, but it looks like that’s what im in for. {sigh }

FYI; sessions in MODx Revo use a custom database table; it’s definitely not a permissions issue. And looking more and more like a problem with your pdo_mysql client.

Quote from: OpenGeek at Mar 25, 2010, 04:47 PM

FYI; sessions in MODx Revo use a custom database table; it’s definitely not a permissions issue. And looking more and more like a problem with your pdo_mysql client.

My understanding is if the php.ini setting ’session.save_path="C:\path\to\session\save\directory"’ directory on IIS doesnt have proper read/write permissions, you’ll get a silent exit/fail almost all of the time.

...So if the function calls to ’getoption’ or ’loadclass’ touches anything concerning the global php session, it could cause the failure... (if it doesnt touch global php session in any way, just ignore me)

Quote from: wowzow at Mar 25, 2010, 05:02 PM

Quote from: OpenGeek at Mar 25, 2010, 04:47 PM

FYI; sessions in MODx Revo use a custom database table; it’s definitely not a permissions issue. And looking more and more like a problem with your pdo_mysql client.

My understanding is if the php.ini setting ’session.save_path="C:\path\to\session\save\directory"’ directory on IIS doesnt have proper read/write permissions, you’ll get a silent exit/fail almost all of the time.

...So if the function calls to ’getoption’ or ’loadclass’ touches anything concerning the global php session, it could cause the failure... (if it doesnt touch global php session in any way, just ignore me)

Nope, nothing will touch anything except the custom session handler. This is definitely not related to session.save_path which is totally ignored by the database session handler provided with Revo.

Quote from: wowzow at Mar 25, 2010, 05:02 PM

My understanding is if the php.ini setting ’session.save_path="C:\path\to\session\save\directory"’ directory on IIS doesnt have proper read/write permissions, you’ll get a silent exit/fail almost all of the time.

My session directory has the correct permissions, and I’m not using IIS, but Apache (most current XAMPP version). As OpenGeek said, it doesn’t seem as if it could have anything to do with that. And I don’t have any problem with other scripts that use sessions, neither with my own scripts nor with other CM Systems, shop systems or whatever else.

Quote from: OpenGeek at Mar 25, 2010, 04:47 PM

And looking more and more like a problem with your pdo_mysql client.

Hm, what could be the problem there? I’m using pdo_mysql a lot myself and never had a problem. Do you do something unusual with it?

// Edit: BTW: As stated in the thread in the NuSphere forum, the debugger DLL also interferes with the PEAR command and crashes the CLI when returning from PEAR::popErrorHandling(). Did anyone else encounter this issue?

Cheers,
Jan