> The stack trace I am interested in shows the exact calling context.
> There are 16 different places where fgets() is called. The first thing
> I'd need to know is which of those 16 places is the call that fails.
I can't get a useful stack trace when the debugger faults while reading the
stack. I need to install Softice and set it to the default debugger in VS
Well, when in doubt... Start hacking the code to pieces. It is definitely
in the http.c file. I am almost certain that it is related to the PERL
helper. I get the message "Bad Command Or File Name" printed to the console
just before the crash. (Some glitch in the error handling, I presume ;)
Here is the only thing that I can figure:
Some code between line 404 to about 427 of http.c seems to be causing the
I can comment out the below line and the debugger starts behaving. Mark
seems correct, the stack appears to be trashed by a buffer overflow.
This seems to corrupt the stack and kills my debugger;
http.c line 411:
fgets(buffer, sizeof(buffer), fp);
The real problem is possibly (or related expressions):
http.c line 404-406:
command = (char *)emalloc(strlen(spiderdirectory) + strlen(url) +
strlen(tmpdir) + strlen(commandline) + strlen(spiderprog) + 32);
sprintf(command, commandline, spiderdirectory, spiderprog, tmpdir,
I don't think that one could call the PERL helper in this manner on Windows.
Any ideas? Am I doing something stupid? What would it take to make this
BTW, I have no major need for the functionality, I am merely interested in
seeing it work. So, I am in no hurry to fix it. I am sure that I would
make some use it if it worked, though.
World Wide Web - http://www.geocities.com/CapeCanaveral/Lab/1652/
Illusionary Web - http://illusionary.dyn.ml.org/ <-- 02:00 - 10:00 GMT
Video/Audio Phone - callto:illusionary.dyn.ml.org
Page via mail - firstname.lastname@example.org
ICQ Universal Internet Number - 412039
E-Mail - email@example.com
Received on Mon Oct 26 13:07:54 1998