Manual talk:How to debug/Archive 1

Dumping variables
Is there a dump routine in MediaWiki? Since MediaWiki stores HTML for output, var_dump isn't working for me. This is a useful topic for this page. -- skierpage 01:11, 29 April 2006 (UTC)

This information does not work for MediaWiki 1.9 using the provided example. Does anyone have an up to date instructions? It would also be helpful if version information was included when providing examples.


 * There is also the useful '$wgDebugComments' variable. &#91;user:jldupont] 14:11, 1 July 2007 (UTC)

profileinfo.php
When I try to browse to /profileinfo.php, I get a blank page. Judging by the source of said file, even if profiling is disabled, there should still be something there. I don't even get any HTML let alone visible content. Any ideas?


 * See Manual:Errors and Symptoms. Is that the problem?  --Cneubauer 19:55, 29 May 2008 (UTC)

Stack Backtrace
Is there a way to get a full stack backtrace with MediaWiki, or do I have to use PHP's Advanced PHP debugger? —Sledged (talk) 16:54, 19 October 2007 (UTC)


 * You can use the wfDebug functions  and  .  You basically put those in your code somewhere to get your backtrace.  If you use the Die one, it will error out to the screen.  The other writes to your debug log.  See GlobalFunctions.php for more information.  --Cneubauer 19:52, 29 May 2008 (UTC)

What are these table columns?
Has anyone ever bothered to document these table columns somewhere?:

Calls        Total          Each             %       Mem      (and three more without headings)


 * Is Calls DB calls, function calls, something else?
 * Total what?
 * What is the content of the three unlabelled columns?

--Michael Daly 06:18, 13 April 2008 (UTC)


 * Just taking a shot at this, but it looks like Calls is the number of times a code block that is surrounded by a wfProfileIn/wfProfileOut pair is encountered. This roughly translates to function calls but in some cases may be smaller pieces like loops within functions that someone chose to add profile info to.


 * Total is the time that it took to run through that part of the code. Not sure what the units are.  Maybe microseconds as the profiler uses microtime.  Each is the amount of time spent in one visit to that code.  So Calls * Each = Total.  % is the percent of total code execution spent in that code block.  Mem is the amount of memory used in the code block?  I get negative numbers for some of that column though so...


 * The two numbers in parens seem to be the min and max of something. Possibly the min and max execution time for all runs through that Call.  The last number is the overhead of something.  Maybe of running the profiler?  It would be great if the developers took time to write up some documentation on things like this but they are unfortunately pretty universally of the school that coding is more important then documenting.  --Cneubauer 19:48, 29 May 2008 (UTC)

Missing information

 * Shouldn't this article (rather than the talk page) include reference to  and  ? I knew about the former but only discovered the latter from this talk page.
 * And 09:10, 5 February 2009 (UTC) Hmmm - perhaps I'm not doing something quite right, but  produced absolutely no output at all for me.

Not working for me at all
I added the calls to localsettings but when I go to profileinfo.php I keep getting the message "query failed: Table 'cojoilustrado.wiki_profiling' doesn't exist"

By what I got from the instructions information can be logged in a file, but profileinfo keeps asking for a table in a database even though I disabled database logging. Here's what I added to localsettings:

$wgShowSQLErrors = true; $wgDebugDumpSql = true;

$wgDebugLogFile = "$IP/stats/debug_log.txt"; $wgEnableProfileInfo = true; $wgDebugLogFile = "$IP/stats/log_info.txt"; /** Only record profiling info for pages that took longer than this */ $wgProfileLimit = 0.1; /** Don't put non-profiling info into log file */ $wgProfileOnly = false; /** Log sums from profiling into "profiling" table in db. */ $wgProfileToDatabase = false; /** If true, print a raw call tree instead of per-function report */ $wgProfileCallTree = false; /** Should application server host be put into profiling table */ $wgProfilePerHost = false; /** Detects non-matching wfProfileIn/wfProfileOut calls */ $wgDebugProfiling = false; /** Output debug message on every wfProfileIn/wfProfileOut */ $wgDebugFunctionEntry = 0;

Am I missing something? Thanks in advance for you help. --Mark 20:11, 2 December 2009 (UTC)

StartProfiler.php
Our documentation here on how to setup StartProfiler looks out of date. I believe we use the autoloader now. Daniel Friesen (Dantman) 17:21, 29 November 2011 (UTC)

Debug Toolbar
I endabled $wgDebugToolbar=true; which was a nice feature. After an update to the most recent version of MediaWiki the debug messages that were generated using wfDebugLog( "modulename","message" ); didn't show up any more. (I'm not sure if the problem is caused by the update, or if there is an other reason for that.) Is there a way to re-enable this nice feature? --Schubi87 (talk) 15:02, 17 October 2012 (UTC)

Cannot get system to write to a log file
I have the following statement in my test wiki LocalSettings.php file:

IOW it is a web-server accessible directory. Both the debug directory and the file (I created it manually when the system didn't) currently have 777 permissions. But nothing is written to the file. I must be missing something pretty damned obvious but cannot find what. Any suggestions much appreciated --Sabretache (talk) 17:51, 12 November 2013 (UTC)