Printable View
I made a completely functional text editor with ncurses using a doubly linked list of text lines as its data model. I just wonder how do I implement scrolling and compensation for line wrapping, preferably without iterating through all the lines.
EDIT: I see that I forgot a space in the title, but I can't edit it.
For scrolling, for example the page down key, just make the top line either the current last line (if you want to scroll with 1 line overlap) or the next line after the current last line to be the top line, then re-drive your display loop.
For line at a time scrolling, I would use the arrow keys. For example, if the current cursor-line is the top displayed line, and you sense the arrow up key, then make the current-top-line minus 1 (Well, make it MAX(CURRENT-TOP-LINE-1,0)), and re-drive your display loop. If ncurses allows the typematic effect, just keep doing it.
I already did it and to completely avoid the possibility of a line taking up more than a line when viewed I made the current line scroll horizontally, with indicator characters ('<' and '>' in reverse video) to show that there is more to be seen past the edge.
To avoid iterating the whole text, I made the print function take a parameter that says what line the linked-list element it was given is on.
The display works great, but the problem is that on occasion is segfaults.:mad:
Congratulations MTK! (you managed that quicker than I would have guessed)Quote:
Originally Posted by MTK
I'm sure it is tempting to blame ncurses at this point, but the three apps I use the most are FF, mc, and vim. The last two are both ncurses based and never seg fault.
So it's probably just an overflow somewhere, just keep re-reading thru your code, think about "off by one" errors because they really are the most common IMO, and maybe try and catch a fault in gdb if you can get it to happen often enough.
I wasn't saying it's ncurses's fault.
It is probably some small thing in the memory management code.
I didn't say you did! We may be right! (good luck)Quote:
Originally Posted by MTK
MTK, do you not have a debugger?
Yes, my distro came with gdb (GNU DeBugger).
Is it possible to run my program in gdb and after a segfault to get a stack trace and examine variable contents?
gdb does not work perfectly with some APIs, I dunno about nucurses, but it is worth trying.Quote:
Originally Posted by MTK
If the seg fault is happening in a predictable way, run it under gdb until the fault occurs, and examine the output. If you are lucky, it will point right to the problem.
If not, it will lay the blame somewhere in the ncurses library. This is because you overflowed and "nicked" it. However, consider that probably the two regions in memory are part of the same call stack. So if you can figure out which ncurses function went wrong, look around in the calling function (or the function that called that function) and you may be able to find the guilty variable near-by. The headache occurs when the function pointed to by gdb is internal to ncurses (eg, not something from your own code), in which case you may be confronting the daunting task of trying to figure out which ncurses routine that you used, used that indicated routine internally (oh joy).
You can also step thru, line by line, using breakpoints, if the fault is predictable enough (eg, you can replicate it easily).
The segfault only happens when I rapidly and randomly hit characters, the Enter key, and the arrow keys at the same time. If I do this there should be a segfault after a second or two.
I heard that gdb has a tty command so it can direct the program's I/O to a different terminal.
One thing you can do with GDB is attach onto an already-running process. So you can launch your program, then figure out its processid and attach onto it with something like this (presumably in a different terminal):
That way your program runs as normal (after you type "continue", of course), but when it segfaults, you just switch terminals to GDB and see what happened.Code:$ ps aux | grep program
... <some PID> ...
$ gdb ./program <some-PID>
Absolutely -- "bt" or "backtrace" will give you your backtrace. You can type "up" and "down" or "frame N" to switch to a different function in the stack trace. And "print <something>" lets you print any C expression, so you can look at a variable with "print variable" or "p variable".Quote:
Is it possible to run my program in gdb and after a segfault to get a stack trace and examine variable contents?
[edit] You can also redirect your program's output as you said, but I think the method I described is more likely to work. [/edit]
So I assume that the program must be compiled with debug info, right?
And how do I find out its PID?
I showed you. Sort of. :) Use "ps aux".
Here's a real example.
I'll compile and run the code to make sure it works. Notice that I compile with debugging information (-g).
Looks good. Now I'll run the program again:Code:$ cat greet.c
#include <stdio.h>
#include <string.h>
int main() {
char name[BUFSIZ], *p;
printf("Enter your name: ");
fgets(name, sizeof name, stdin);
if((p = strchr(name, '\n'))) *p = 0;
printf("Greetings, %s.\n", name);
return 0;
}
$ gcc -g greet.c -o greet
$ ./greet
Enter your name: dwk
Greetings, dwk.
$
In another terminal, I now type the following. "px aux" lists the processes which are running. grep searches for the string "greet" in this list; it finds the process and it finds itself too.The second number in ps aux's output is the process ID. The command on the right shows you which program is which.Code:$ ./greet
Enter your name:
I've attached onto the process, and it is stopped for now by GDB until I type "continue" (or "c" for short). Now I can see what's happening.Code:$ ps aux | grep greet
dwk 29133 0.0 0.0 1516 328 pts/5 S+ 16:27 0:00 ./greet
dwk 29135 0.0 0.0 3908 668 pts/6 S+ 16:27 0:00 grep greet
$ gdb ./greet 29133
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
Attaching to program: greet, process 29133
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x008d8402 in __kernel_vsyscall ()
(gdb)
Hmm, looks like name is uninitialized. Let's set a breakpoint after this line, to let fgets() finish.Code:(gdb) bt
#0 0x008d8402 in __kernel_vsyscall ()
#1 0x0099aa43 in __read_nocancel () from /lib/libc.so.6
#2 0x0093ba28 in _IO_file_read_internal () from /lib/libc.so.6
#3 0x0093cd80 in _IO_new_file_underflow () from /lib/libc.so.6
#4 0x0093d47b in _IO_default_uflow_internal () from /lib/libc.so.6
#5 0x0093e7ed in __uflow () from /lib/libc.so.6
#6 0x00932176 in _IO_getline_info_internal () from /lib/libc.so.6
#7 0x009320c1 in _IO_getline_internal () from /lib/libc.so.6
#8 0x0093103a in fgets () from /lib/libc.so.6
#9 0x08048443 in main () at greet.c:8
(gdb) frame 9
#9 0x08048443 in main () at greet.c:8
8 fgets(name, sizeof name, stdin);
(gdb) print name
$1 = '\0' <repeats 5492 times>,
"�\203*\000\000\000\000\000�%\000\000�����/+\000����@�)\
000\000\220�\000�%\000\000\003\000\000\0002\000\000\000����", '\0'
<repeats 45 times>,
"\220\215\000\000`�\000\234Q�\000\234Q�\000\000\000\000\000\005\000\000\00
0\000`�\000\000\220�\000|\211�\000���\000\000�\023\000\003\000\000
\0001�*\000�/+\000j\002\000\000X6+\0004���e�*\000\b\000\000\000�/+
\000/\000\000\000\000���L���e�*\000\b\000\000\000\017\000\000\000�
��/+\000\230���\\)*\000p����?+\000\017\000\000\000\001\000\000\000
\000"...
(gdb)
Now GDB has released control of the program and it's running once again. At this point I go to the other terminal and type "dwk" into the program. Back in GDB,Code:(gdb) l
3
4 int main() {
5 char name[BUFSIZ], *p;
6
7 printf("Enter your name: ");
8 fgets(name, sizeof name, stdin);
9
10 if((p = strchr(name, '\n'))) *p = 0;
11
12 printf("Greetings, %s.\n", name);
(gdb) break 12
Breakpoint 1 at 0x8048468: file greet.c, line 12.
(gdb) continue
Continuing.
So there you have it.Code:Breakpoint 1, main () at greet.c:12
12 printf("Greetings, %s.\n", name);
(gdb) print name
$2 = "dwk", '\0' <repeats 5489 times>,
"�\203*\000\000\000\000\000�%\000\000�����/+\000����@�)\
000\000\220�\000�%\000\000\003\000\000\0002\000\000\000����", '\0'
<repeats 45 times>,
"\220\215\000\000`�\000\234Q�\000\234Q�\000\000\000\000\000\005\000\000\00
0\000`�\000\000\220�\000|\211�\000���\000\000�\023\000\003\000\000
\0001�*\000�/+\000j\002\000\000X6+\0004���e�*\000\b\000\000\000�/+
\000/\000\000\000\000���L���e�*\000\b\000\000\000\017\000\000\000�
��/+\000\230���\\)*\000p����?+\000\017\000\000\000\001\000"...
(gdb) continue
Continuing.
Program exited normally.
(gdb) quit
$
I did as you told, and got a backtrace in gdb of where the segfault occurs, but I cannot print out the function's locat variables!
Here is the offending function:
A screenshot of the debugging session is in the attachment.Code:void ll_ins_str(LINKED_LINE* ll, char* str, unsigned long col) //Insert string
{
unsigned long len = strlen(str);
ll_realloc(ll, ll->len+len); //Reallocate RAM
memmove(ll->text+col+len, ll->text+col, (ll->len-col+1)*sizeof(char)); //FIXME segfault
memcpy(ll->text+col, str, len*sizeof(char)); //Paste in new string
ll->len += len;
}
Judging from the info in the screenshot, you need to change the frame context. When you issued the backtrace command to gdb, you got a list of the stack frames; in your case there were five. If you issue the command frame, gdb will tell you which frame context you are currently in. Certainly you will not be in frame 2, for if you were, you would have been able to print the value of len. So run your program as before, issue the backtrace command. When you get the list of frames, choose the frame number corresponding to the function you want to examine, and use frame <number> to get into that context. Then you can issue the print command to examine the variable.Quote:
Originally Posted by MTK
A couple of other minor notes:
1) You are using gcc/gdb - so when you compile, turn on as much debugging info as you can. There are levels to the amount of debugging info you can compile into the executable. For example, the -g option takes 4 options itself, -g0, -g1, -g2, -g3. -g0 is no debugging info (i.e. it negates using -g at all), whereas -g3 is the most amount of debugging info. Using -g by itself defaults to -g2. There is also a gdb specific option, -ggdb, which may or may not produce a little more debugging info as well (It is my understanding that it depends on the system). If you are only debugging with gdb (as opposed to dbx), you may as well use the -ggdb as opposed to the -g flag, as it is intended to work best with gdb. The -ggdb option also defaults to -ggdb2, but you can set the level to -ggdb0, -ggdb1, or -ggdb3 also. Give it a try!
2) I find Peter's gdb Tutorial to be decent enough. If you want to get a pretty good understanding of how to use gdb, go through the lessons, and do the exercises. At the end, you should be able to handle yourself pretty well with gdb.
I fixed it! (with the help of you and gdb):)
Using gdb, I found out that the line in which the string was to be inserted was 0 characters long, and for some reason it was called to insert it in col 3. This was the result of the ll_split_line() function that called it. What it did is:
Insert a blank line.
Copy text after index col to next line (segfault because it inserted it in index col instead of 0).
Delete part of original line after index col.