On Mon, 3 Jan 2005, Thorsten Glaser wrote:
The ?? orgy continues...
[...] #164 0x00000000 in ?? () #165 0xcfbf26d8 in ?? () #166 0x1c0e4f42 in valloc () Previous frame inner to this frame (corrupt stack?)
Do you still suggest to re-try with valgrind or recompiling lynx with find-leaks?
Perhaps. As you see, memory corruption problems can be tedious to resolve. I recall troubleshooting something like this by running lynx with the trace option turned on, and seeing how far it got. (This, of course, for a case which I could reproduce). Then I added more CTRACE's in the general area where the code appeared to die. Some of the CTRACE's are for very low-level calls, and it's hard to see where they are, so adding calls such as
CTRACE((tfp, "%s @%d\n", __FILE__, __LINE__));
to the source above those calls can give some hints. Mostly I rely on
traces to give information (it's rare for me to use more than a half-dozen
gdb commands in a session - walkback, run, print (2-3 different variables).
The one I have in mind was this:
* replace fixed-buffer Style_className[] with a dynamically-allocated buffer,
needed for large pages which lack correctly-nested tags, e.g.,
http://www.aspas-nature.org/petitions/petition2.html
(reported by Frederic L W Meunier) -TDThe problem was that a fixed-buffer (under src) was used for storing a stack of names. When it ran past the end of the buffer, adjacent data was overwritten, causing a secondary problem down in the WWW logic, and finally a core dump.
Narrowing the problem down to see where the first problem can be observed is the first step. The cause may be far removed from the symptom - which is why it's nice to have a case that can be repeated (in debugging, I repeat those cases many times ;-)
-- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
_______________________________________________ Lynx-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lynx-dev
