Hi.

I used to have problems with the internal debugger in version 4.6, until Dmitri found out that I should run index.php by selecting Run in debugger and not the drop down list.

After upgrading to 5.0.1, and trying to debug a site, I have the same problems.
The problem is that my breakpoint is so deep in the code that the debug session is killed before it gets down to it.

As soon as the website frontpage is send the debug session is killed, and in order to get to the breakpoint I would have to login at the website and click on a menu item.

So how can you keep the debug session alive, so it will get to my breakpoint.

Thanks.

what does it mean "debug session is killed"? Did you explicitly stopped debugger or what?
Debugger will stop on the breakpoint as soon as execution reaches it. It does not depend how deep the code is.

When I say that the debug session is killed it goes like this.

I run index.php file in debugger, and when the page is loaded and displayed in the output window the debugger finishes.

"Action", "navigating: http://localhost:8080/file:/C:/www/TechPlat/apache/htdocs/moskb/index.php", "21:33:50", ""
"Action", "Debug session (ID=393048984996200003) started", "21:33:50", ""
"Action", "Debug session finished", "21:34:12", ""

The breakpoint is in a file that can not be executed directly, I have to login to the joomla application before I can execute the code in the file, but the second the frontpage of joomla is loaded the debug session ends as shown in the log dump above.

I had this working on 4.6 after you discovered that I should open the index.php file and select run in debugger, instead of selecting it from the icons drop down list.

Now it does not work again.

Looks like you unchecked "debug sessions" on the debugger settings page.

No I have not, it is untouched, and still checked.

Well, please let me see 3 urls:
1) original url that you started in the browser
2) url for the login script
3) url to the script that executes the file of interest.

1. Original URL when I start the RUN in Debugger.

http://localhost:8080/file:/C:/www/TechPlat/apache/htdocs/moskb/index.php?DBGSESSID=393058038524000001;d=1,p=0,c=1

2. Url when I click login on the website.

http://localhost/moskb/index.php?DBGSESSID=393058038524000001;d=1,p=0,c=1

(looks like the session is still alive here.)

3. Url to the script that executes the file of interest

http://localhost/moskb/index.php?option=com_kb&page=questions&Itemid=27


Ok the above looked interresting, so I decide to try to click on a url that did not requiere me to be loged in to see what happens..

1. The original URL when run in debugger.

http://localhost:8080/file:/C:/www/TechPlat/apache/htdocs/moskb/index.php?DBGSESSID=393058110463100006;d=1,p=0,c=1

2. The url to file where I have placed my breakpoint

http://localhost/moskb/index.php?option=com_weblinks&Itemid=23

so you started in Local SRV mode and Joomla redirected you to 3rd party web server. Isn't it easier to set Run Mode to 3rd party web server, set project root pointing to the web server root and start working with it?

Ok I have change that now, hoped for a minute that it was it.

Now I am using apache and the debug module is loaded..

See :

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with NuSphere PhpExpress v1.4.0, Copyright (c) 2002-2007 NuSphere Corp., by Dmitri Dmitrienko
with the ionCube PHP Loader v3.1.29, Copyright (c) 2002-2007, by ionCube Ltd., and
with DBG v3.2.3, (C) 2000, 2007, by Dmitri Dmitrienko

Ok I start to debug and the url looks like this.

http://localhost/moskb/index.php?DBGSESSID=393058629227500012;d=1,p=0,c=1

I then click on a menu item with a breakpoint and the url now looks like this.

http://localhost/moskb/index.php?option=com_weblinks&Itemid=23

And the debug session is broken.

Ok I put a breakpoint in index.php, and now it works.

Thanks for the help.

Why do you think so?
By looking at the url?
After the first request is made, DBGSESSID is passed in cookie. Just take a look and you'll see.
What important is to click in the same browser instance that started debug session because the cookie is temporary and may not be seen by the other instances. Also, the link should point to the same hostname/domain and with the same protocol (http vs https).
It may appear that Joomla performs some cleanups for the cookies. In this case debug session is broken intentionally or by ommission in the application you're trying to debug. Just add output for the $_COOKIE[] to see if DBGSESSID is there and its value is not negative. If it appears that it's cleaned up, I'd recommend to use hardcoded DebugBreak() calls.

Thanks Dmitri

The hardcoded DebugBreak() will force the debugger to launch right ?

I still quite dont understand why it is not possible to start and stop the debug process manually so you would not have to monitor the cookie.

I mean if you could have a menuitem to switch to debug mode, and you stay in debug mode until you switch it off.
That way any application that you might debug could do what ever they wanted with the cookies and you will be debugging until you decided it was time not to.

When I developed in cobol on mainframe systems (10 years ago) that was possible, and much easier to control.