Debugger that works with modx?

Quote from: enigmatic_user at Mar 25, 2010, 01:03 PM

Quote from: OpenGeek at Mar 25, 2010, 11:47 AM

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?

Not that I’m aware of, but it could be related to either a non-standard session configuration or perhaps a problem with DBG when trying to debug mysql connections in the session calls. I’ll have to do some research, but can you post your session ini values for good measure?

Quote from: OpenGeek at Mar 25, 2010, 01:16 PM

I’ll have to do some research, but can you post your session ini values for good measure?

Of course; I’ll also add my DBG configuration (screenshots from phpinfo()).

Cheers,
Jan

I have to say that DBG works fine for me for many years in different environments and modx+iis+php-5.3 is not an exception. Although modx has some pitfalls during installation process, I managed to go through and debugged some pages. No, there are no problems at all. No crashes.
My config:
iis-5.1 (xp distro)
php-5.3.2 (php.net distro, VC9/NTS package)
modx 1.0.2 (some very obvious modifications are made just to make it working, otherwise it does not start at all)
phped 5.9/5936 (nusphere distro)
dbg 3.8.12 (nusphere distro)
no other extensions like the ones wamp/xamp likes to add (such as accelerators/caches)


What I also tried is xdebug 2/netbeans 6.8, but it didn’t show any local variables. What a shame!

Here’s a dumb question that others might have as well. How do you debug within MODx? I’ve used PhpED to debug snippet code running outside of MODx, but never within it.

Executing /index.php gives me the home page, but any link gives a 404 error.

Executing /manager/index.php gives me the login page, then a 404 error.

Honestly, it was brought to attention by my colleague. I tried modx just for the sake to see the real problem and help him. I’m a nusphere customer, so could submit a report and request for a fix. But no, their product confirmed its status and worked just fine I don’s see what in a snippet could crash two debuggers. But I can guess, it’s a screwed up configuration or broken php (5.3.0 is almost a dead version, 5.3.2 isn’t much better either, I wouldn’t expect anything rock-stable before 2011).

Anyway, if you send me such snippet, I’ll give it a try

Quote from: Jack_hawk at Mar 29, 2010, 11:59 AM

No, there are no problems at all. No crashes.
My config:
[...]
modx 1.0.2

Did you try MODx Revolution? I never tried MODx Evolution (I’m quite new to MODx), and this is a Revolution subforum, so maybe this just affects the new version.

Cheers,
Jan

Quote from: Jack_hawk at Mar 29, 2010, 05:27 PM

I don’s see what in a snippet could crash two debuggers.

It’s no snippet that crashes Apache (yes, it’s the web server that crashes, not the debugger...), it’s MODx Revolution itself - as I stated before, in my case it’s the custom session management. When I load the debugger DLL in the php.ini and then call any MODx Revolution page - including any Manager (backend) page -, httpd.exe crashes. When I exclude the debugger DLL from my php.ini, everything works just fine. As I said, PEAR is affected, too.

Cheers,
Jan

Huh httpd.exe? Looks like you have different configuration than Wowzow who started this thread and reported the problems with iis+php/fastcgi and it’s what I tried and finally found out it works.
Jan, it’s not necessarily the debugger crashing you, even though removing it "fixes" the problem. In fact, you think it’s debugger because you added it last. Try to remove all, absolutely ALL extensions, caches, accelerators, etc, add only mandatory (mysql), and install right debugger module. There are 6 debugger modules for Windows platform, they can not be installed interchangeably because they are compiled for different php binaries.
If you run php as apache module, it can be a challange. AFAIK official Apache binary is still VC6, therefore you can use VC6/TS php only.
Last but not the least, make sure that your versions match mine’ (php+debugger) and most probably you’ll see it works. Otherwise provide the details such as version of the debugger, the directory that you picked the module from, and phpinfo.

PS, I also tried apache that comes with nusphere’s TechPlatform (VC9/TS) with php 5.3.2 php5apache2-2 from php.net, VC9/TS, just removed nusphere’s php, unpacked php.net’s, and rolled up new php.ini from php.ini-production in the php package. It worked fine too.


jack

Quote from: Jack_hawk at Mar 30, 2010, 01:04 AM

Huh httpd.exe? Looks like you have different configuration than Wowzow who started this thread and reported the problems with iis+php/fastcgi and it’s what I tried and finally found out it works.

Yes, I stated that before (posting #20).

Quote from: Jack_hawk at Mar 30, 2010, 01:04 AM

There are 6 debugger modules for Windows platform, they can not be installed interchangeably because they are compiled for different php binaries.
If you run php as apache module, it can be a challange. AFAIK official Apache binary is still VC6, therefore you can use VC6/TS php only.

I’m not new to PHP or PhpED. I wrote about this in the NuSphere forum thread I linked to in posting #13. The version I chose should be correct; it’s the same I used for years (well, it’s newer of course ), and it works perfectly for all other scripts I run or debug - even for MODx Revolution if I disable the custom session management.

Quote from: Jack_hawk at Mar 30, 2010, 01:04 AM

Last but not the least, make sure that your versions match mine’ (php+debugger) and most probably you’ll see it works.

I’m using the most current XAMPP version. I think that should do - at the moment, I don’t have the time to play around with my PHP installation. But did you try MODx Revolution? In posting #23 you spoke of MODx 1.0.2. Besides, I’m not saying that this problem occurs on every system with PhpED’s debugger installed. Yes, most likely there’s a problem with DBG interfering with some other component(s) on my system. But that doesn’t mean that DBG couldn’t be the culprit. A debugger should work with the system I use - if I have do disable Apache modules for making the debugger work, it’s of no use for me.

Quote from: Jack_hawk at Mar 30, 2010, 01:04 AM

Last but not the least, make sure that your versions match mine’ (php+debugger) and most probably you’ll see it works. Otherwise provide the details such as version of the debugger, the directory that you picked the module from, and phpinfo.

I already did some of that in posting #32. I don’t think anybody is willing to compare the complete phpinfo() output with his own...

Cheers,
Jan

Jan, I still see no info from you about your version of the debugger. Is it 3.8.0, 3.8.1, or 3.8.2?

and it works perfectly for all other scripts I run or debug - even for MODx Revolution if I disable the custom session management.

This suggests you’re using php 5.3.1. Did you try php-5.3.2?

if I have do disable Apache modules for making the debugger work, it’s of no use for me.

Did I say anything like this? If you read my post you’ll see that I didn’t mention Apache modules at all.
Although, if you have any non-standard apache module (provded by a 3rd party) it make sense to try turning it off too.
What I meant is to disable php’s modules.
You’re using XAMPP it’s full of stuff that you don’t really need and that’s what do crash apache+php.
Try official php binaries+official apache binaries and you’ll find they work much more stable.

But that doesn’t mean that DBG couldn’t be the culprit

Oh well, if your brother came into the room when Apache crashed, does it mean your brother is a culprit?
TWO DIFFERET DEBUGGERS were tried and it’s alone is a strong evidence to believe they are not the problem. Also
I installed two configurations - apache+php and iis+php. Neither crashed modx.