Visualize Backtrace doesn't work on Windows machines
litwol - November 15, 2007 - 06:52
| Project: | Visualize Backtrace |
| Version: | 5.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs review |
Description
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.)
#1
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.
#2
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.
#3
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.
#4
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.
#5
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 ....
#6
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...
#7
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
#8
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 Offxdebug.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
#9
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!
#10
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.
#11
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
#12
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;
}
#13
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?
#14
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.
#15
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!
#16
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?
#17
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).
#18
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.
#19
.following. May understand better later on and try-out to implement. ;-)