If you're using a PSLG, you've probably failed to specify a proper set of bounding segments, or forgotten to use the -c switch. Or you may have placed a hole badly, thereby eating all your triangles. To test these possibilities, try again with the -c and -O switches. Alternatively, all your input points may be collinear, in which case you can hardly expect to triangulate them.
Triangle doesn't terminate, or just crashes.
Bad things can happen when triangles get so small that the distance between their vertices isn't much larger than the precision of your machine's arithmetic. If you've compiled Triangle for single-precision arithmetic, you might do better by recompiling it for double-precision. Then again, you might just have to settle for more lenient constraints on the minimum angle and the maximum area than you had planned.
You can minimize precision problems by ensuring that the origin lies inside your point set, or even inside the densest part of your mesh. On the other hand, if you're triangulating an object whose x coordinates all fall between 6247133 and 6247134, you're not leaving much floating-point precision for Triangle to work with.
Precision problems can occur covertly if the input PSLG contains two segments that meet (or intersect) at a very small angle, or if such an angle is introduced by the -c switch, which may occur if a point lies ever-so-slightly inside the convex hull, and is connected by a PSLG segment to a point on the convex hull. If you don't realize that a small angle is being formed, you might never discover why Triangle is crashing. To check for this possibility, use the -s switch (with an appropriate limit on the number of Steiner points, found by trial-and-error) to stop Triangle early, and view the output .poly file with Show Me. Look carefully for small angles between segments; zoom in closely, as such segments might look like a single segment from a distance.
The numbering of the output points doesn't match the input points.
You may have eaten some of your input points with a hole, or by placing them outside the area enclosed by segments. Alternatively, you may have several points with identical coordinates; if so, Triangle will print a warning message and throw the duplicates away.
Triangle executes without incident, but when I look at the resulting mesh, it has overlapping triangles or other geometric inconsistencies.
If you select the -X switch and thereby turn off exact arithmetic, Triangle's divide-and-conquer Delaunay triangulation algorithm could make mistakes due to floating-point roundoff error. Don't use the -X switch. If you still have problems, report the bug to me, and use the -i switch to select the slower but more robust incremental algorithm, which hasn't failed me yet.
If you have problems refining a triangulation not produced by Triangle: Are you sure the triangulation is geometrically valid? Is it formatted correctly for Triangle? Are the triangles all listed with their corners in counterclockwise order?