WebLord

Solving Problems

Debugging Levels

Increase the debugging level for increasingly detailed information on processing details.

Unexpectedly Missing Text on a Page

Determining causes for text gone missing.

Runnaway Recursion

Tackling runnaway recursion problems.

Memory Allocation Problems

Out of memory: what to do.

WebLord has several debugging levels, set with the DEBUG=n argument. Each debugging level includes the output of all lesser levels.

WARNING: Debug levels 6 or higher can produce hundreds of kilobytes of output! It is highly recommended that output be redirected to a file, then examined with a text editor or similar tool.

0	Set either with DEBUG=0 (or QUIET) Suppresses all output except errors.
1	The default output/verbosity level Adds progress feedback as pages are being processed and written to disk.
2	Set with DEBUG=2 Adds feedback on if/ifdef/ifndef decisions being made and other minor revelations.
3	(currently the same as 2)
4	(currently the same as 2)
5	Set with DEBUG=5 Adds feedback on objects read from the input definition.
6	(currently the same as 5)
7	Set with DEBUG=7 Adds lots(!) of details on individual tokens retrieved from the input file. Be careful with this one, as it can produce hundreds of kilobytes of output!
8	(currently the same as 7)
9	Set with DEBUG=9 The highest possible, most verbose debug level; this is currently equivalent to level 7

Most likely this is due to some conditionals (if / ifdef / ifndef) resolving to an unexpected value. You should try debug level 2 to determine if all conditionals resolve to the values that you expect.

Once WebLord has descended 1000 levels or deeper (if this ever happens, you almost certainly have a problem!!) into resolving object values, it begins to issue warnings, printing to the output the symbols to be resolved for approximately 10 recursion levels. After about 10 levels, it stops, and begins again at 1250, 1500, 1750, 2000, etc.

Future versions of WebLord will provide enhanced recursion detection and provide diagnostics as to the problem's cause. You are currently left to determine the problem on your own. Some of the following may be of assistance:

1. If you make any reference to 'name' (or an object being referenced makes itself a reference to 'name', etc.) then you may be inadvertently referencing the wrong value and might cause WebLord to resolve an infinitely recursive definition. See the Misconceptions and Pitfalls section for an explanation on this particular issue.

   Any object referencing another, which in turn somewhere "down the line" references back upon the same list of references will also cause infinite recursion. Example: Object A references object B. Object B then references object C, and object C references object A again.

Debug level 2 may also shed some light on the matter.

It is possible that many requests for dynamic memory allocation and subsequent releases of this memory have resulted in a high degree of fragmentation of the available free memory. Depending on the degree of this fragmentation, the largest consecutive block of memory may be comparatively small.

WebLord requires memory in comparatively large blocks (as much as twice the size of your largest page), so when memory is seriously fragmented, an allocation may fail and WebLord will be unable to proceed.

WebLord's own impact on the system's memory fragmentation is either minor or non-existent due to its use of memory pools, which are allocated and extended in large chunks.

Once memory is significantly fragmented there are two methods to getting WebLord to function: quit all other programs, thereby giving the system a chance to consolidate memory into larger chunks again. If this is not successful (it not always is) then rebooting your system is the only remaining solution.