Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.)
Comment | File | Size | Author |
---|---|---|---|
#17 | visualize_backtrace.zip | 25.96 KB | tech_nick |
Comments
Comment #1
KentBye CreditAttribution: KentBye commentedNot 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.
Comment #2
litwol CreditAttribution: litwol commentedafter 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.
Comment #3
KentBye CreditAttribution: KentBye commentedThanks 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.
Comment #4
Gunny-1 CreditAttribution: Gunny-1 commentedlitwol/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.
Comment #5
Gunny-1 CreditAttribution: Gunny-1 commentedwell 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 ....
Comment #6
KentBye CreditAttribution: KentBye commentedGunny,
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...
Comment #7
Gunny-1 CreditAttribution: Gunny-1 commentedNot 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
Comment #8
KentBye CreditAttribution: KentBye commentedSo 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:
FULL XDebug info from phpinfo():
Comment #9
KentBye CreditAttribution: KentBye commentedOkay.
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!
Comment #10
kenorb CreditAttribution: kenorb commentedI'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:
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:
Tested on Windows. Should work on Linux/Unix also.
Comment #11
kenorb CreditAttribution: kenorb commentedFollowed function should be rewrited to Windows/Mac compability also (without `ls` command):
http://php.net/manual/en/function.scandir.php
Comment #12
picco CreditAttribution: picco commentedI 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.
Comment #13
ccdoss CreditAttribution: ccdoss commentedI'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?
Comment #14
tech_nick CreditAttribution: tech_nick commentedI'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.
Comment #15
KentBye CreditAttribution: KentBye commentedGreat. 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!
Comment #16
ccdoss CreditAttribution: ccdoss commentedI 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?
Comment #17
tech_nick CreditAttribution: tech_nick commentedThis 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).
Comment #18
ccdoss CreditAttribution: ccdoss commentedThat 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.
Comment #19
David Naian CreditAttribution: David Naian commented.following. May understand better later on and try-out to implement. ;-)
Comment #20
13rac1 CreditAttribution: 13rac1 commentedClosing ancient issue for unsupported version. There is a feature request for 7.x Windows support in:
#1196188: Upgrade module to work on Windows