Everyone experiences them. Everyone hates them. They're the frickin' level leak. Below are some causes and effects, and a number of ways you can deal with leaks.
First, you should know what causes them. The most common cause of a leak is a gap in your level that "leaks" into the void. Look at the picture below.
What you see is an obvious gap. Through the gap is an area outside the level. When this gap exists, the compile tools don't know what is inside and what is outside the level. Because of this, the BSP process will report its LEAK LEAK LEAK error, and VIS will not run, and RAD will only perform direct lighting calculations (that is, no light bounces).
Sometimes these gaps aren't quite so obvious. They can be as little as one unit wide and still cause a leak.
Another big cause of leaks is having a point entity outside the level. All point entities must be inside valid level space.
One more cause is when you seal off your level with a brush entity, like a func_door. Brush entities are ignored where visibility by the engine is concerned, and so they also count as a leak if they are contacting both the inside and the outside (the void) of the level. They create the same condition as if there were a gap in their place.
A leak in a level has a number of bad effects. First, the BSP process will report the leak, and it will not produce a portal file (mapname.prt). The portal file is used by the VIS process to perform its visibility calculations. Since there is no portal file, VIS will not run at all. When VIS doesn't run, it doesn't produce the files necessary for the RAD process to calculate its light bounces. Due to this, the RAD process will only perform direct lighting - no light bounces. (If you are using Zoner's Half-Life compile tools - you should be! - the RAD process won't run at all)
The most serious effect by far is that the VIS process will not run when a leak is present. When the level is run in Half-Life, the rendering engine will not have any visibility info available with which to limit itself, so it will attempt to draw the entire level. This will most certainly lead to high polygon counts and may lead to things like doors, items, and the sky blacking out or not being drawn if the maximum rendered polygon limit (which is 800 polygons in software rendering mode) is reached.
There are a number of ways to deal with leaks. The first way you should check is by loading the pointfile. Make sure that mapname.pts is being copied into the valve\maps folder along with the compile map (you'll have to move it manually otherwise). The .pts file contains a set of coordinates that form a line of dots that should lead you to the leak. To load the pointfile in the game, bring down the console and type pointfile.
You will see a message similar to 1050 points read, and you should see something similar to the above picture. (You may have to run about your level to find it).
The default engine limit is 2048 points, which may not be enough to trace a line to the leak in your map. If this is the case, start Half-Life at the command prompt with "hl -particles 10000" (or some higher number) to allow the engine to display more particles, and thus trace a longer line to help you find your leak.
When you've loaded the pointfile, type "noclip" to allow you to walk through walls and "r_fullbright 1" to make the map bright so you can see everything. (If you're using Zoner's compile tools, the map will already be fullbright since the RAD process didn't run.) If there are monsters placed in the level, typing 'god' and 'notarget' at the console will make things easier as well. The 'notarget' command causes monsters not to become hostile to your presence, and 'god' makes you immune to damage of any sort. If you noclip outside the level, it might also be useful to type 'gl_clear 1' in the console. This will turn the void into a solid color, rather than the mess that it will be if you're using the glide or opengl renderer.
Once you find the line, follow it. It bounces all over the place, goes in screwy directions, both inside and outside the level. At some point, it will pass through a hole in the walls of your level. There's your leak.
The Big Block Method
If your level is especially large and you're having difficulty tracking down your leak, you might benefit from using the "Big Block Method" of leak tracking. What this is essentially, is you covering a large portion of your level with a solid block (make sure it goes completely through from top to bottom). A recommended size is a quarter of your level.
Place the large block over a portion of your level, then attempt to compile. Move the block to a new section and recompile until the leak error disappears. When this happens, you know the leak is somewhere within the space of the block. Now you can repeat the procedure using a smaller block, only within the space that was covered last with the big block.
This method would only work, of course, if you had one leak, or a number of leaks that would all be covered at once by the block.
Neal White adds this about the Big Block method:
I discovered the Big Block Method on my own, but I use it for an entirely different purpose. It is *very* helpful in tracking down those damn leaf-saw-into-leaf portal bugs. It's the only good way I've found to track them down. It also can be used to drastically reduce your level compile times when you just need to test the lighting in a room or two.
The Bright Light Method
Some people favor this method over the big block, but depending on the level, it can be very time consuming. It involves placing a large box around the entire level, then placing a number of very bright purple (or other easily visible color) lights inside the box, but outside what would be your level. Now, compile the level, and since the level is inside a big box, it should compile fine, and the RAD process should also run fine. Once its in the game, run around your level looking for the light leaks.
The main drawback to this is that the compile for the map may take an exceptionally long time, and you'd probably be better off using the pointfile method, but this method may work better if you're faced with multiple leaks throughout your level.
Note: Some people would point out - if placing a box around your level gets rid of the leak, why not stop there? Well, it gets rid of the leak, but it doesn't get rid of the main bad effect of the leak - VIS still cannot properly optimize the level because it doesn't know what is inside or outside the level. You will still see the high polygon counts and poor framerate. This is not a solution.
An Ounce of Prevention
It was pointed out to me that I originally missed talking about the most important way to fix leaks, and this is by preventing them in the first place. Take your time when building, make sure things are snapped properly to the grid. This is the note I received -
this is where the phrase "an ounce of prevention is worth a pound of cure" comes in.. ie: take your time .. make sure all wall joins are solid and thick .. I always make 64 unit walls all around the outside of my map and then build detail inside of that .. this allows me to see if I happen to have misaligned brushes ...
The 64 unit thick walls aren't completely necessary, but they will make it more obvious if you have a misaligned brush. The whole point is, be careful, be attentive, take your time. I'll end this before it sounds like a father/son lecture.
Leaks are bad, and can be really frustrating to find. Hopefully this information has shed a little bit of light on the subject for those that need it. Also remember, sometimes a good eye is all that's needed to find the leak. Look around the level in the editor - look for gaps or misaligned brushes, point entities in the void, etc. Kill those leaks!