i'm not sure what to say... it just doesnt work for me.

it installs, it generates reports. but when i try to view the reports i loose coloring of cuntions and most of the time i get wsod (memory is not an issue.)

CommentFileSizeAuthor
#17 visualize_backtrace.zip25.96 KBtech_nick
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

KentBye’s picture

Status: Active » Fixed

Not seeing the proper color coding means that something is happening with the visualize_backtrace_get_lookup_table_values() section of the code.
I suspect that you may have chosen the "drupal60_cvs" option instead of "local."
The official 6.x release hasn't been made yet, and so I don't have any data pointing to the external CVS url permalink, and so try using your local copy.

Are you using Drupal HEAD or the Beta2 of Drupal?
I got it working on beta2, and am waiting for the next release candidate or official release.

By generating reports, I'm assuming that you mean that XDebug is generating trace files.
And I assuming that viewing the reports means that you're visiting the '/visualize_backtrace/1195198417/hide_callstack/all_sections' page and it is parsing the trace files into the three sections, and you're able to see the Full Function Call Stack for this Trace.

And I sometimes get WSOD when the trace file is too big -- i.e. > 3MB

If that worked for you, then go ahead and mark the status of this issue from fixed to closed.
Or re-activate it if you need more info.

litwol’s picture

after looking at the code i realized what the problem was... i was running it on a windows machine. you should note somewere that this module doesnt work at all on windows.

as for the other problems, i got them when running it on mac. i will take some time later to debug it more thoroughly.

KentBye’s picture

Title: d6 branch doesnt work well » Visualize Backtrace doesn't work on Windows machines
Version: 6.x-1.x-dev » 5.x-1.1
Priority: Normal » Critical
Status: Fixed » Active

Thanks litwol,
I changed the title to reflect the problem, and it makes sense that it worked on a Mac, but not on your windows machine.

I added this disclaimer to the project page:
NOTE: This module was developed on a Mac development environment, and so at the moment it does not work on windows machines due to some linux-specific commands. Follow this issue for more details and follow-up.

I did some feedback from another person saying that awk commands were required, and that they should be rewritten in PHP. And pwd may have a Drupal core workaround. Sorry for not filing a bug report, but now this confirms that it's part of the problem.

Let me know what other things are hanging up on your windows machine.

Thanks.

Gunny-1’s picture

litwol/kentbye ... i could get the trace files generated to C:\drupal\tmp ... but when i go to http://drupal/?q=view_traces ... i get the text that says "The most recent trace files are listed ..." but there isnt any trace files listed here ...
i understand this is something to do with the path setting ... may i know how you fix this for windows in the source code ...

did you set the php_value xdebug.profiler_output_dir "C:\drupal\tmp" in php.ini or .htaccess. I did those changes in .htaccess, my php_ini xdebug has the output_dir pointed to /tmp ... so i believe the .htaccess overrides php.ini

When i click the following link "Generate Backtrace Data for this Page Load" after enabling the block ... it goes to http://drupal/?q=visualize_backtrace//hide_callstack/all_sections ... there is a extra '/' before hide_callstack
No dot files are generated due to the above issues. Appreciate your help.

Gunny-1’s picture

well http://drupal/?q=test_xdebug ... says "XDebug is not properly creating trace files yet" so the function xdebug_get_tracefile_name() called in visualize_backtrace_test_xdebug() isnt firing at all ... though trace files are getting generated in the output dir. This is really weird .. how about linux/unix or is it happening only in windows. i am using php-xdebug-2.0.1-5.1.2.dll ....

KentBye’s picture

Gunny,
Not sure if this is related to Windows or an isolated problem, and so I'll keep the discussion in this issue until we discover otherwise.

Hmmm... Well, that's really weird that XDebug is creating trace files, but not picking up on them with xdebug_get_tracefile_name().

You can try to manually type in the tracefile number into the URL argument to see if it even parses (i.e. http://drupal/?q=visualize_backtrace/1195258677/hide_callstack/all_sections )

I should note that you don't have clean URLs enabled, and I'm not sure if my module requires them to be turned on or not. I'll check and see since I usually default to having them enabled.

Here's something that I typed up after #4, but before re-reading #5:
Take a look at the latest INSTALL.txt file since there may be some more details added since the 5.x-1.1 release, but you should be able to go to a phpinfo() page and see that XDebug is set up properly first. Then test to see if trace files are being generated. The missing argument in this URL http://drupal/?q=visualize_backtrace//hide_callstack/all_sections is the trace file number -- which should be the timestamp of the page load (e.g. something like 1195258677).
You may need some help from Google searches in finding a good XDebug installation tutorial.

Let me know if you get it to work, or else let's open a separate issue for this...

Gunny-1’s picture

Not yet, if i place the timestamp of the generated trace file in the url it results in a white screen (as before).
The trace files are getting generated as before in the xdebug.profiles folder. I dont have clean urls installed as i am running on localhost (with vhosts hence the name drupal / whatever ) and clean urls cant be enabled. Looked at the code and figured out
Overriding the php.ini xdebug values in .htaccess as given in Install.txt.

xdebug related info -> phpinfo

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with Xdebug v2.0.2-dev, Copyright (c) 2002-2007

xdebug.auto_trace	Off	Off
xdebug.collect_includes	On	On
xdebug.collect_params	0	0
xdebug.collect_return	Off	Off
xdebug.collect_vars	Off	Off
xdebug.default_enable	On	On
xdebug.dump.COOKIE	no value	no value
xdebug.dump.ENV	no value	no value
xdebug.dump.FILES	no value	no value
xdebug.dump.GET	no value	no value
xdebug.dump.POST	no value	no value
xdebug.dump.REQUEST	no value	no value
xdebug.dump.SERVER	no value	no value
xdebug.dump.SESSION	no value	no value
xdebug.dump_globals	On	On
xdebug.dump_once	On	On
xdebug.dump_undefined	Off	Off
xdebug.extended_info	On	On
xdebug.idekey	TADASTU$	no value
xdebug.manual_url	http://www.php.net	http://www.php.net
xdebug.max_nesting_level	100	100
xdebug.profiler_aggregate	Off	Off
xdebug.profiler_append	Off	Off
xdebug.profiler_enable	Off	Off
xdebug.profiler_enable_trigger	Off	Off
xdebug.profiler_output_dir	/tmp	/tmp
xdebug.profiler_output_name	cachegrind.out.%p	cachegrind.out.%p
xdebug.remote_autostart	Off	Off
xdebug.remote_enable	Off	Off
xdebug.remote_handler	dbgp	dbgp
xdebug.remote_host	localhost	localhost
xdebug.remote_log	no value	no value
xdebug.remote_mode	req	req
xdebug.remote_port	9000	9000
xdebug.show_exception_trace	Off	Off
xdebug.show_local_vars	Off	Off
xdebug.show_mem_delta	Off	Off
xdebug.trace_format	0	0
xdebug.trace_options	0	0
xdebug.trace_output_dir	/tmp	/tmp
xdebug.trace_output_name	trace.%c	trace.%c
xdebug.var_display_max_children	128	128
xdebug.var_display_max_data	512	512
xdebug.var_display_max_depth	3	3
KentBye’s picture

So it looks like you're running into the Windows limitations with the awk command and others, which is to be expected.

I'm currently making some fivestar improvements that I hope to get in before the next major 1.9 release, but I hope to take a look at this early next week since there are now 2-3 people waiting on this.

Something that you can look into if you have time is see what the alternative Drupal command for determining the base path is. The pwd & ls commands are linux-specific & may probably need changing. This is used for listing the latest trace files at /view_traces as well as determining the file sizes on the splash page. I add a warning to indicate whenever the *.dot file is over a certain size because the ZGRViewer either hangs or takes a long time to load.

The next order of business would be converting the crazy command defined in $parse_trace_command of the visualize_backtrace_generate() function. The linux specific awk text stream processing command needs to be ripped out and replace with a PHP approach.
There is a lot of extraneous data in the original trace file, and this sorts the wheat from the chaff and also references the previous PHP function line numbers whenever a procedural hook is called (i.e. like preg_replace_callback or call_user_func_array). That's because XDebug records the line number of 0, and makes it difficult to see where the procedural hook is actually called.

As far as your XDebug setup, it looks like something is still not completely being setup correctly.
I'm not sure if your .htaccess is correctly passing along the info to XDebug.
Below is a complete dump of my XDebug variables (which I'll probably end up rolling into the INSTALL.txt as a reference)

NOTE: I'm using the RC3 version of XDebug 2.0.0 since I had troubles upgrading (!)
So the trace_output_name variable may be a bit different if you're using 2.0.1 -- I believe it should be "trace.%t" instead -- or else try "timestamp"

But the key values are the following:

xdebug.auto_trace	On	Off
xdebug.trace_format	1	0
xdebug.trace_output_name	timestamp	crc32
xdebug.trace_output_dir	/tmp	/tmp

FULL XDebug info from phpinfo():

xdebug
xdebug support	enabled
Version 	2.0.0RC3

Directive	Local Value	Master Value
xdebug.auto_trace	On	Off
xdebug.collect_includes	On	On
xdebug.collect_params	Off	Off
xdebug.collect_return	Off	Off
xdebug.collect_vars	Off	Off
xdebug.default_enable	On	On
xdebug.dump.COOKIE	no value	no value
xdebug.dump.ENV	no value	no value
xdebug.dump.FILES	no value	no value
xdebug.dump.GET	no value	no value
xdebug.dump.POST	no value	no value
xdebug.dump.REQUEST	no value	no value
xdebug.dump.SERVER	no value	no value
xdebug.dump.SESSION	no value	no value
xdebug.dump_globals	On	On
xdebug.dump_once	On	On
xdebug.dump_undefined	Off	Off
xdebug.extended_info	On	On
xdebug.idekey	kent	kent
xdebug.manual_url	http://www.php.net	http://www.php.net
xdebug.max_nesting_level	100	100
xdebug.profiler_aggregate	Off	Off
xdebug.profiler_append	Off	Off
xdebug.profiler_enable	On	Off
xdebug.profiler_enable_trigger	Off	Off
xdebug.profiler_output_dir	/tmp	/tmp
xdebug.profiler_output_name	timestamp	crc32
xdebug.remote_autostart	Off	Off
xdebug.remote_enable	On	On
xdebug.remote_handler	dbgp	dbgp
xdebug.remote_host	127.0.0.1	127.0.0.1
xdebug.remote_log	no value	no value
xdebug.remote_mode	req	req
xdebug.remote_port	9000	9000
xdebug.show_exception_trace	Off	Off
xdebug.show_local_vars	Off	Off
xdebug.show_mem_delta	Off	Off
xdebug.trace_format	1	0
xdebug.trace_options	0	0
xdebug.trace_output_dir	/tmp	/tmp
xdebug.trace_output_name	timestamp	crc32
xdebug.var_display_max_children	128	128
xdebug.var_display_max_data	512	512
xdebug.var_display_max_depth	2	2
KentBye’s picture

Okay.
I ripped out a number of *nix-specific 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 to see if it's working for you.

NOTE: If you have the jQuery UI Backport module installed & enabled, then you can now have sortable tables!

kenorb’s picture

Status: Active » Needs review

I've tested dev version, but there is problem with detecting tracefile path on Windows.
There is issue in visualize_backtrace_get_xdebug_tracefile_path() function:

function visualize_backtrace_get_xdebug_tracefile_path() {
  // The trace number and trace path can be found w/ the xdebug_get_tracefile_name() command
  // usually something like "/tmp/trace.1189698885.xt"
  // Recreate the trace file path and then include open trace file of interest
  $trace_path_array = explode("/", xdebug_get_tracefile_name());
...

So i.e. xdebug_get_tracefile_name() will return filename:
C:\\wamp\\logs\\xdebug/trace.drupal-__q=visualize_backtrace_drupal-__q%3Dtest_xdebug%28032164%29_hide_callstack_all_sections(040e4b).log.xt
and visualize_backtrace_get_xdebug_tracefile_path() function will return path '/' instead of 'C:\wamp\logs\xdebug', because it's trying to explode '/' instead of '\' on Windows machine.

My solution is to replace visualize_backtrace_get_xdebug_tracefile_path() function with following:

function visualize_backtrace_get_xdebug_tracefile_path() {
    return dirname(xdebug_get_tracefile_name()).'/';
}

Tested on Windows. Should work on Linux/Unix also.

kenorb’s picture

Followed function should be rewrited to Windows/Mac compability also (without `ls` command):

function visualize_backtrace_display_latest_traces() {
  $trace_path = visualize_backtrace_get_xdebug_tracefile_path();  

  // First retrieve the trace values that have already been parsed
  $get_parsed_trace_files_command = "ls ". $trace_path ."trace.*.xtparsed";
  exec($get_parsed_trace_files_command, $parsed_trace_files_output);

  // Set a flag for each trace_number that have been already parsed.
  foreach ($parsed_trace_files_output as $parse_trace_value) {
    $parsed_trace_number = explode('.', $parse_trace_value);
    $parsed_trace_flag[$parsed_trace_number[1]] = TRUE;
  }

  // Now retrieve all of the XDebug traces that have been created
  $get_trace_files_command = "ls ". $trace_path ."trace.*.xt";
  exec($get_trace_files_command, $trace_files_output);

  $output = '';

  // Reverse the order to show the most recent trace files first
  krsort($trace_files_output);
  foreach ($trace_files_output as $trace_value) {
    $trace_number = explode('.', $trace_value);
    $trace_number[1];
    if ($parsed_trace_flag[$trace_number[1]]) {
      $parsed = ' * has already been parsed';
    }
    else {
      $parsed = '';
    }
    $output .= l($trace_value, 'visualize_backtrace/'. $trace_number[1] .'/hide_callstack/all_sections') . $parsed .'<br />';
  }
  
  return $output;
}

http://php.net/manual/en/function.scandir.php

picco’s picture

I rewrote the function for my Windows enviroment and added the time interval also to the output.
I haven't made any patches to drupal yet, but feel free to modify and make a patch out of it.

/**
 * Menu_Callback to display the latest XDebug traces
 */
function visualize_backtrace_display_latest_traces() {
  $output = '';
  $now = time();
  $results = array();
  $parsed = array();
  $trace_path = visualize_backtrace_get_xdebug_tracefile_path();
  $files = scandir($trace_path, 1);

  foreach ($files AS $file) {
    if (is_file($trace_path.$file) && preg_match("/trace\.(\d+)\.xt(parsed)?/", $file, $m)) {
      if (empty($m[2])) {
        $results[] = array('path' => $trace_path . $file, 'stamp' => $m[1], 'age' => format_interval($now - $m[1]));
      }
      else {
        $parsed[] = $m[1];
      }
    }
  }

  foreach ($results AS $result) {
    $output .= l($result['path'], 'visualize_backtrace/'. $result['stamp'] .'/hide_callstack/all_sections') . ', ' . $result['age'] . (in_array($result['stamp'], $parsed) ? t(' * has already been parsed') : '') .'<br />';
  }

  return $output;
}
ccdoss’s picture

I've tried setting this thing up on a windows machine. For some reason, when I view the phpinfo() file through http://localhost, it shows xdebug is setup (both under the Powered by Zend block and as its own module). However, when I view it under admin/logs/status/php, it only shows xdebug under the Powered by Zend part. It indicates that they're pointing to the same php.ini file. What am I doing wrong?

tech_nick’s picture

I've made code working on my Windows machine this night. Well, it seems everithing's fine, need some time to have a rest and then I'll describe what troubles was met and how i've solved them.

KentBye’s picture

Great. Thanks tech_nick, if you upload your file or diff patch to this queue then I'm sure that it'd help a lot of other windows users. I don't really have access to a Windows server environment to test it. Thanks!

ccdoss’s picture

I am now getting traces in my files directory (that's where .htaccess puts them). However, when I try to visualize the traces, I get the following:
Warning: fopen(/trace..xtparsed) [function.fopen]: failed to open stream: No such file or directory in C:\AppServ\www\drupal5\modules\visualize_backtrace\visualize_backtrace.module on line 378

What's wrong?

tech_nick’s picture

FileSize
25.96 KB

This message comes because there is no *.xtparsed file at all in your folder.
Unix function awk should be changed to gawk - windows adoptation of awk. Donwload and put it to one of path directories.
Awk script is different for windows, you can track changes in attached file, it works on my windows+denver (php.5.2+mysql.4.*+apache).

ccdoss’s picture

That seems to have solved the previous problem. Test_debug works, and I can now see a bunch of files when I click "View All Past Trace Files". However, I don't know how to generate .dot files. Now, when I click on Generate Backtrace Data, I get the following error:
( ! ) Warning: fopen(C:/AppServ/www/files/1208537693_section0.dot) [function.fopen]: failed to open stream: No such file or directory in C:\AppServ\www\drupal5\modules\visualize_backtrace\visualize_backtrace.module on line 950

Also, I don't know why it's looking in C:/AppServ/www/files/, when in .htaccess I state the path is C:\AppServ\www\drupal5\files.

I read the install file, but don't see where that's generated. I haven't installed ZGRViewer, but it seems to be geared toward viewing .dot files, not creating them.

David Naian’s picture

.following. May understand better later on and try-out to implement. ;-)

13rac1’s picture

Status: Needs review » Closed (won't fix)

Closing ancient issue for unsupported version. There is a feature request for 7.x Windows support in:
#1196188: Upgrade module to work on Windows