I have been stuck for a while on a statement that causes a segmentation fault when commented out, from some of the information about this that I gathered people were saying that my stack was getting corrupted somewhere or somehow.
http://pastebin.com/NT8PGPi0
the code that cause the segmentation fault line number 511 (sorry for all the newlines linux didn't like when I copied it out of the editor)
basically with this project it should be able to print a .txt to the screen with different options chosen by the user for instance
./a.out --delete=c // deletes all the c's in the file and spots it to the console
./a.out --line-numbers // posts all the line numbers in the console
so on and so forth with the long options, same with the short options.
As was mentioned, the best option in such situation is always debug code by gdb or another debuger. But as a small hint. Look at this in Opt_Args function:
*c = getc(fp);
And then look at manual for getc:
int getc(FILE *stream);
Related
I'm sorry about the weird snippets. I won't be able to paste the exact code.
The following list from an ELF file shows addresses and commands at them.
0x4000XXXX: [someInstr] [someReg], [someReg2], [someReg3]
0x4000XXXY: [someInstr] [someRegValue], [somereg3]
0x4000XXXZ: [jumpInstruction] [someReg3] + 0xXXX, [someReg4]
0x4000XXXA: [someInstr]
0x4000XXXB: [someInstr]
0x4000XXXC: [someInstr]
0x4000XXXD:
The third instruction adds 0xXXX [which is some address value] to value in someReg3 register. Going there,
0x4000YYYY: [someInstruction]
0x4000YYYZ: [someInstruction]
0x4000YYYX: [someInstruction]
0x4000YYYA:
we see that the execution will stop once 0x4000YYYA address comes up as it is blank. [The instructions above it are all linear ones like OR, AND etc.]
My question is, why are the blanks even there?
In the example I gave above, I have no idea where the exact "ending" instruction resides, but using nm -S [filename] and readelf -l [filename] I was able to estimate 2 end points. Unfortunately, those addresses have unimplemented instructions and it causes interruptions in the program. The file has quite a lot of blank spaces but I've only included 2 for an example. These blanks are interrupting the program I'm running. Even if I skip the execution at these addresses, I have no idea where to stop.
I'm talking about this things:
warning: ds segment base generated, but will be ignored in 64-bit mode
I know that -w option can be used to suppress warnings in NASM, but from the list of warnings showed by the help menu nothing fits this type of warning. And -w-all gets rid of everything, except this.
Any way of doing this?
Since that particular error doesn't seem to be one of the suppressible ones (as you've stated, I'd just use sed as a post-processing step, piping the output through something like:
sed '/^warning: .. segment base generated, but will be ignored in 64-bit mode$/d'
Even if you're using nasm on Windows, you can still get the GNUWin32 port of sed to do the job.
And before you complain about this being a kludge, you should know that some of my greatest achievements were kludges, and many of them have out-lived my more well-designed code.
:-)
I have a problem here...
I'm using debug (in cmd/ms-dos) to learn some things and to peforme some commands... I set AX to 1234 and DX to ABCD.
So, I did '-a 100' to register a instruction, I did: mov ah,dl
And them "-g" (because I set an interruption) or "-g 102" to peforme the instruction and stop before 102 offset (if I not set the interruption).
When I peform -r to show me the registers values, they remain unchanged, this should be AX:CD34, but AX is 1234 yet, looks like the MOV command doesn't works... what am I doing wrong?
http://img203.imageshack.us/img203/4866/movdxdldoesntworks.png
(sorry for the link, I need reputation to post image)
I also would like to know if exists something like Windows Debug to Linux, I mean, I have nasm and yasm in my Linux installation (Debian-based), but it's just a compiler, I need to write the code into a file, and compile it to run, we have some "emulator" or "debug" tool for ASM in Linux? Like the Debug windows software in the picture above?
The last thing, sorry to make the message so long with 3 questions, but I don't want to "flood" with a lot of topics, so, my last question is where can I find some kind of list of interruptions? I would like to find some list or manual with machine code functions. In Peter Norton's book, for example, when I have "02h" in the "AH" register, I tell to DOS to print one character in the screen, and he said "if you want to find a list of functions, you can look your DOS manual", well, I can't find this dos manual (in linux we can type "man" and we have manuals for everything), the windows "help" function is only a list for simple commands, not a real manual like the unix "man".
I try to find it in google, but every "DOS manual" did I found only show me simple functions like "cd, dir, format, time, blablabla", nothing real technical about the system or something... Can you help-me in find some complete list of "AH" commands and functions?
I know INT 18h is for run Basic and INT 19h restarts the computer (a guy said to me, 18h for him doesn't run basic but restarts the computer instead of INT 19h). I also find 2 or 3 more occurrences in Google, but not a "complete" list, someone have it?
Thanks for the help, patience and attention, I love you! ;)
Please try it again with:
.g=cs:0100 0102
http://www.armory.com/~rstevew/Public/Tutor/Debug/debug-manual.html
.........
RBIL: Ralf Browns x86/MSDOS Interrupt List
http://www.pobox.com/~ralf
http://www.pobox.com/~ralf/files.html
ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/
Dirk
It is hard to say why it does not work in your debugger.
Did you try to just type this in your program and put breakpoint at the end of it to see the result?
Here is an answer to the question about linux debugger (they recommend GDB):
Linux Assembly Debugger
For the third question here you have a good source of info about interrupts: http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html
In case link gets outdated search for "Ralf Brown's Interrupt List"
I'm debugging my linux kernel module. It causes deadlock and i'm trying to figure out how. I'm using vmware + gdb. The idea is to hook the function and log backtrace into the file. I'm trying the following:
(gdb) br _raw_spin_lock
Breakpoint 5 at 0xffffffff815eb700: file kernel/spinlock.c, line 136.
(gdb) commands 5
Type commands for breakpoint(s) 5, one per line.
End with a line saying just "end".
>silent
>bt
>continue
>end
but continue doesn't work here. If i replace bt with echo 1 it works. Is there way to log information every time the function is called?
Thank you.
Most likely you are hitting gdb pagination prompt.
https://sourceware.org/gdb/onlinedocs/gdb/Screen-Size.html
Run this before setting the breakpoint
set height 0
You don't say why it doesn't work. What exactly goes wrong?
Normally this kind of thing works fine. Putting "continue" into a breakpoint's commands is something I've done routinely for years. It isn't without problems (it interferes with "next") but if you are just doing logging or the like, it works great.
One guess would be that the "bt" is failing with an error. This would cause the commands to abort and, I believe, the inferior to stop at the breakpoint. Then the question is, what exact error message is emitted? Or perhaps you're hitting pagination. Or maybe some other thing I haven't thought of :-)
If it's an error, one possible option might be to limit the backtrace.
I'm using Microsoft Visual C++ 6.0 and trying to debug someone else's program. I tried to use printf statements but for some reason, these statements are not shown on the screen as the program runs. I am able to use fprintf to print these statements to file, but this is useless when the program crashes in the middle of execution, as the file would be empty then.
How can I force some output to screen?
To force output to the screen, please see the first section below. The second and third options below are also good for debugging program crashes like these.
Using printf with fflush (refinement of Vishal Kumar's answer)
Vishal Kumar's answer worked for me, but I had to do a little research to find out how to use fflush. I had a problem where my program was crashing "in the middle" of a printf statement which did not make sense. Here is my refinement of his answer. In cases where a debugger is difficult to use (e.g. multithreading), you can use fflush after every printf (or fprintf) statement. For example, "pepper your code" with:
... // code
printf("Part 1 executed successfully");
fflush(stdout); // flushes the stdout buffer
... // further code
printf("Part 2 executed successfully");
fflush(stdout);
... // repeat as necessary
Run, observe the output, and put more print statements between the last statement that prints, and the first statement that doesn't print, until you isolate the problem.
Debugger
If you are able to use a debugger, it is a more efficient choice than peppering your code with output statements as described above, but there are cases where you have to resort to that.
Valgrind
If you are using Linux (which I gather you are not because it is in MS Visual C++), valgrind is another option to see where your code is crashing (and for detecting memory leaks). If your code is compiled for debug, if your program is called "myProgram", you can just call from the terminal window as follows:
valgrind myProgram