There is an awk command that processes the trace files that is giving people some troubles, and is probably more trouble than its worth to debug.

It's also a *nix dependency that is giving some windows users some problems.

So one task is to re-write it in native PHP.

I hope to take a look at this within the next 2-3 days, and at least release a new 5.x-dev release.

CommentFileSizeAuthor
#1 trace.1195524099.xt_.txt895.4 KBteshager

Comments

teshager’s picture

teshager commented
StatusFileSize
new trace.1195524099.xt_.txt895.4 KB

I'm adding a unparsed raw xt file for your reference

KentBye’s picture

KentBye commented

Thanks.

On first look I can already tell that you're going to have problems with it because it's missing the 5th column with the memory usage!

Here's a snippet of my working trace:

Version: 2.0.0RC3
TRACE START [2007-11-20 07:22:56]
1	0	0	0.000866	58904	{main}	1		/Library/WebServer/Documents/head/index.php	0
2	1	0	0.015714	296056	require_once	1	/Library/WebServer/Documents/head/includes/bootstrap.inc	/Library/WebServer/Documents/head/index.php	12
3	2	0	0.015838	296692	define	0		/Library/WebServer/Documents/head/includes/bootstrap.inc	13
3	2	1	0.015880	296692
3	3	0	0.015898	296692	define	0		/Library/WebServer/Documents/head/includes/bootstrap.inc	18
3	3	1	0.016126	296692
3	4	0	0.016140	296692	define	0		/Library/WebServer/Documents/head/includes/bootstrap.inc	23

Here's a snippet of your trace that is breaking:

Version: 2.1.0-dev
TRACE START [2007-11-20 02:01:39]
1	0	0	0.000644		{main}	1		/Applications/MAMP/htdocs/d53/index.php	0
2	1	0	0.001289		require_once	1	/Applications/MAMP/htdocs/d53/includes/bootstrap.inc	/Applications/MAMP/htdocs/d53/index.php	12
3	2	0	0.001379		define	0		/Applications/MAMP/htdocs/d53/includes/bootstrap.inc	13
3	2	1	0.001479	
3	3	0	0.001491		define	0		/Applications/MAMP/htdocs/d53/includes/bootstrap.inc	18
3	3	1	0.001552	
3	4	0	0.001563		define	0		/Applications/MAMP/htdocs/d53/includes/bootstrap.inc	23

I also notice that you have a 2.1.0-dev version, and it looks like they might have changed the specs on the trace_format. The latest official release from xdebug is 2.0.2, and so it looks like you're really on the bleeding edge with 2.1.0-dev

You may want to poke around to see why you're not getting any memory usage data on that fifth column.

nadavoid’s picture

nadavoid commented

My log files also were in the wrong format. I was using the 2.1.0-dev because that's what was bundled in the latest version of Komodo. I couldn't find an option for xdebug to put into my .htaccess file that would correct the format. I downloaded the xdebug.so from your site and used it in place of the 2.1.0-dev one, and the logging is in the correct format now.

KentBye’s picture

KentBye commented

hmm... Well, maybe I need to put in a special note for Komodo users then.

It's nice to know that there is a workaround for it by downloading this xdebug.so version on my website, but it's annoying that they're shipping a xdebug.so file that has a different trace log format. Ugh....

@c4rider: Try downloading and pointing to this xdebug.so file.

The underlying issue of re-writing the awk command in PHP remains, but note to self that there may need to be some additional logic that checks the trace log version number.

teshager’s picture

teshager commented

Hi Kent,

I have been out of town and just saw your note. I will upload the xdebug you've recommended and will report back my findings in few hours. Thanks for all the help!

BTW, I'm also using the newest Komodo release (4.2)

/c4rider

teshager’s picture

teshager commented

Hi Kent,

Is this for PHP 5.1 or 4.4? I tried the xdebug for both and would not start my apache server when used in 4.4 and generates the following error message when run with 5.1:

PHP Fatal error: Call to undefined function xdebug_get_tracefile_name() in /Applications/MAMP/htdocs/d53/sites/default/modules/visualize_backtrace/visualize_backtrace.module

Will need to do further debugging, FYI.

/c4rider

KentBye’s picture

KentBye commented

Good news.
I've eliminated the awk file and replaced it with a PHP-native approach, and it turns out that it actually accounts for empty columns whereas the awk command didn't.
This means that the visualize_backtrace.module will properly account for the missing memory data in that 2.1.0-dev XDebug trace file.

I haven't uploaded the results yet since I have to rewrite some other things and fix a couple of other bugs.
But I hope to get a dev release out soon for testing.

KentBye’s picture

KentBye commented
Status: Active » Fixed

Okay.
I ripped out the awk command in the dev version of Visualize Backtrace, which can be downloaded with this terminal command:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-5 -d visualize_backtrace contributions/modules/visualize_backtrace

There are some other tweaks that need to be made, but could someone on a Windows machine or who was having troubles give this version a few tests.

NOTE: If you have the jQuery UI Backport module installed, then you will also have sortable tables!

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.