Emacs - GDB trace right to interrupt without stepping through all files

Question

I am working on Pintos OS project. I get this message:

Page fault at 0xbfffefe0: not present error writing page in user context.

The problem with Pintos OS project is that it won't simply tell the line and method that caused the exception.

I know how to use breakpoints/watchpoints etc. but is there any way to step right to it without going through the WHOLE flow and ALL OS files line by line so that I could jump into line that caused exception and put breakpoint there? I looked at GDB commands but didn't find anything.

When I debug this project I have to step through the whole program until I find that error/exception which is very time consuming. There is probably a faster way to do this.

Thanks. Whole trace:

nestilll@vdebian:~/Class/pintos/proj-3-bhling-nestilll-nsren/src/vm/build$ pintos -v -k -T 60 --qemu --gdb  --filesys-size=2 -p tests/vm/pt-grow-pusha -a pt-grow-pusha --swap-size=4 -- -q  -f run pt-grow-pusha
Use of literal control characters in variable names is deprecated at /home/nestilll/Class/pintos/src/utils/pintos line 909.
Prototype mismatch: sub main::SIGVTALRM () vs none at /home/nestilll/Class/pintos/src/utils/pintos line 933.
Constant subroutine SIGVTALRM redefined at /home/nestilll/Class/pintos/src/utils/pintos line 925.
warning: disabling timeout with --gdb
Copying tests/vm/pt-grow-pusha to scratch partition...
qemu -hda /tmp/N2JbACdqyV.dsk -m 4 -net none -nographic -s -S
PiLo hda1
Loading............
Kernel command line: -q -f extract run pt-grow-pusha
Pintos booting with 4,088 kB RAM...
382 pages available in kernel pool.
382 pages available in user pool.
Calibrating timer...  419,020,800 loops/s.
hda: 13,104 sectors (6 MB), model "QM00001", serial "QEMU HARDDISK"
hda1: 205 sectors (102 kB), Pintos OS kernel (20)
hda2: 4,096 sectors (2 MB), Pintos file system (21)
hda3: 98 sectors (49 kB), Pintos scratch (22)
hda4: 8,192 sectors (4 MB), Pintos swap (23)
filesys: using hda2
scratch: using hda3
swap: using hda4
Formatting file system...done.
Boot complete.
Extracting ustar archive from scratch device into file system...
Putting 'pt-grow-pusha' into the file system...
Erasing ustar archive...
Executing 'pt-grow-pusha':
(pt-grow-pusha) begin
Page fault at 0xbfffefe0: not present error writing page in user context.
pt-grow-pusha: dying due to interrupt 0x0e (#PF Page-Fault Exception).
Interrupt 0x0e (#PF Page-Fault Exception) at eip=0x804809c
 cr2=bfffefe0 error=00000006
 eax=bfffff8c ebx=00000000 ecx=0000000e edx=00000027
 esi=00000000 edi=00000000 esp=bffff000 ebp=bfffffa8
 cs=001b ds=0023 es=0023 ss=0023
pt-grow-pusha: exit(-1)
Execution of 'pt-grow-pusha' complete.
Timer: 71 ticks
Thread: 0 idle ticks, 63 kernel ticks, 8 user ticks
hda2 (filesys): 62 reads, 200 writes
hda3 (scratch): 97 reads, 2 writes
hda4 (swap): 0 reads, 0 writes
Console: 1359 characters output
Keyboard: 0 keys pressed
Exception: 1 page faults
Powering off...

Answer 1

to have the GDB debugger run and stop at the desired location:

gdb filename <--start debug session br main <--set a breakpoint at the first line of the main() function r <--run until that breakpoint is reached br filename.c:linenumber <--set another breakpoint at the desired line of code c <--continue until second breakpoint is encuntered

The debugger will stop at the desired location in the file, IF it ever actually gets there,

Answer 2

When I debug this project I have to step through the whole program until I find what caused error/exception which is very time consuming. There is probably a faster way to do this.

Normally what you would do is set a breakpoint just before the error. Then your program will run at full speed, without your intervention, until it reaches that point.

There are several wrinkles here.

First, sometimes it is difficult to know where to put the breakpoint. In this case I suppose I would look for the code that is printing the message, then work backward from there. Sometimes you have to stop at the failure point, examine the stack, set a new breakpoint further up, and re-run the program.

Then there is the mechanics of setting the breakpoint. One simple way is to break by function name, like break my_function . Another is to use the file name and line number, like break my_file.c:73 .

Finally, sometimes a breakpoint can be hit many times before the failure is seen. You can use ignore counts (see help ignore ) or conditional breakpoints (like break my_function if variable = 27 ) to limit the number of stops.