19 Feb, 2009, boblinski wrote in the 1st comment:
Votes: 0
Well, the title says it… everything compiles fine, then when I boot up and it asks me:

Do you want ANSI? (Y/n)

If I select Yes.. it runs fine.. but if I select No.. it crashes.

How do I 'debug' this problem? or is it normally an easy fix?
19 Feb, 2009, David Haley wrote in the 2nd comment:
Votes: 0
See Nick Gammon's very good guide to debugging with gdb.
19 Feb, 2009, boblinski wrote in the 3rd comment:
Votes: 0
Wow, thats a little too complicated for me I think…
19 Feb, 2009, David Haley wrote in the 4th comment:
Votes: 0
Well, you have to start somewhere :smile: You asked how to debug it; that link is the answer. It probably is an easy fix. For what it's worth, nobody can help you anyhow without asking questions like "what is the backtrace from gdb?".
19 Feb, 2009, boblinski wrote in the 5th comment:
Votes: 0
I'm using Cygwin. This is what I tried-

insight ../src/rom

*source window and console window appear*

in console window i type-
run 4000

*my mud starts
*I crash my mud

*window opens *warning*- Program received signal SIGSEGV, Segmentation fault
*I click OK

*source window pops opens up and displays a segment of code within "comm.c"–
(line 2044 is highlighted)
-	2032	            write_to_buffer (d, buf, point2 - buf);
2033 }
2034 else
2035 {
- 2036 for (point = txt; *point; point++)
2037 {
- 2038 if (*point == '{' && *point– != '{')
2039 {
2040 point++;
2041 continue;
2042 }
- 2043 *point2 = *point;
- 2044 *++point2 = '\0';
2045 }
- 2046 *point2 = '\0';
- 2047 write_to_buffer (d, buf, point2 - buf);
2048 }
2049 }
2050 return;
- 2051 }
2053 void page_to_char (const char *txt, CHAR_DATA * ch)
- 2054 {
2055 const char *point;
2056 char *point2;

I've got no idea what is wrong with this code (if anything) and I've never edited it..

What do I do?
19 Feb, 2009, elanthis wrote in the 6th comment:
Votes: 0
You have most likely gone past the end of the buffer pointed to by point2, which would be `buf` I believe. Not enough code is displayed to offer a fix, but a possible "quick and dirty" fix would be to just increase the size of said buffer. A more correct fix would be to add checks to make sure that point2 never goes past the end of the buffer: that is, if point2 - buf >= sizeof(buf), bail out (make sure you leave the buffer NUL-terminated).
19 Feb, 2009, Sharmair wrote in the 7th comment:
Votes: 0
Actually, over running a buffer a few bytes seldom causes a SIGSEGV like this, at least not directly.
A SIGSEGV means you are accessing invalid memory, and that is normally out of range memory. But
the valid memory is not allocated on a data element size level, but normally in just a few (at most)
large blocks. So a slight over run is much more likely to corrupt other data (or go unnoticed), though
then using that other data might very well cause a crash.

But in this case, the problem is quite evident in the code you posted. The problem is line 2038 in your
if (*point == '{' && *point– != '{')

This if can never be true as the char can not both be { and not be { at the same time. But if you
ever hit a { in the text you are trying to send to the character, it will try to evaluate this line and
though it will be false, it has the side effect of backing up the read of the input text to the char
before the {. Then the code after the if prints that char to the output, (well, over and over again).
The input read gets stuck on that char and not only over runs the buffer, but runs out of control
until it finally goes out of valid memory range (maybe going megabytes).

That 2nd part of the if, the part after the && is wrong and should be removed. It is not really
clear what was intended here, my best guess would be to have {{ print just {, but to do that
you could look at the next char in the if and if it was not an { then continue. Maybe something
if(*point == '{'){
if(*point != '{')
19 Feb, 2009, David Haley wrote in the 8th comment:
Votes: 0
It's sort of surprising that such a simple bug would be lurking in the ROM codebase.
19 Feb, 2009, Tyche wrote in the 9th comment:
Votes: 0
DavidHaley said:
It's sort of surprising that such a simple bug would be lurking in the ROM codebase.

It's not. That is the code here is some twisted modified derivative of ROM.