I have a C application that is executing in an HP-UX environment and I need to get the stacktrace.
I am attempting to use U_STACK_TRACE, but output to stderr is going somewhere else and I need it printed to a string.
How can I do this?
I.E. How can I take the output from U_STACK_TRACE and put it in a string instead of it being written to stderr.
U_STACK_TRACE() prints a formatted stack trace to standard error. _UNW_STACK_TRACE() produces a formatted stack trace on the output stream indicated by parameter out_file. The stream must be a writable stream for output to be produced.
So, open a file using fopen() and call _UNW_STACK_TRACE() instead of U_STACK_TRACE().
Related
I'm writing a C program and I would like to be able to store data inside the executable file.
I tried making a function to write a single byte at the end of the file but it looks like it can't open the file because it reaches the printf and then gives "segmentation fault".
void writeByte(char c){
FILE *f;
f = fopen("game","wb");
if(f == 0)
printf("\nFile not found\n");
fseek(f,-1,SEEK_END);
fwrite(&c,1,sizeof(char),f);
fclose(f);
}
The file is in the correct directory and the name is correct. When I try to read the last byte instead of writing it works without problems.
Edit: I know I should abort the program instead of trying to write anyway but my main problem is that the program can't open the file despite being in the same directory.
There are several unrelated problems in your code and the problem you're trying to solve.
First you lack proper error handling. If any function that can fail (like e.g. fopen) fails, you should act accordingly. If, for example you did
#include <error.h>
#include <errno.h>
...
f = fopen("game","wb");
if ( f == NULL ) {
error(1,errno,"File could not be opened");
}
...
You would have recieved an useful error message like
./game: File could not be opened: Text file busy
You printed a message, which is not even correct (the file not beeing able to be opened is somthing different, than not beeing found) and continued the program which resulted in a segmentation fault because you dereferenced the NULL pointer stored in f after the failure of fopen.
Second As the message tells us (at least on my linux machine), the file is busy. That means, that my operating system does not allow me to open the executable I'm running in write mode. The answers to this question lists numerous source of the explanation of this error message. There might be ways to get around this and open a running executable in write mode, but I doubt this is easy and I doubt that this would solve your problem because:...
Third Executable files are stored in a special binary format (usually ELF on Linux). They are not designed to be manually modified. I don't know what happens if you just append data to it, but you could run into serious problems if your not very careful and know what you're doing.
If you just try to store data, use another plain and fresh file. If you're hoping to append code to an executable, you really should gather some background information about ELF files (e.g. from man elf) before continuing.
I have basically a C compiled binary wherein if an error is encountered during the execution, the error is dumped out to stderr. This C Binary is wrapped around NodeJS, where the binary is invoked via child process exec. But upon error, even though C code dumps out the information to stderr, I still seem to get the information in Nodejs on stdout, and not on stderr. So, essentially running console.log(stdout); dumps out the error information but console.log(stderr); dumps nothing. Does anyone have any idea on this, and if I need to redirect this information through a different medium so I get appropriate information on stdout and stderr on NodeJS script?
I created a test version of the code and it seems to display the information correctly on stderr and stdout:
#include <stdio.h>
int main(){
fprintf(stderr, "Whoops, this is stderr");
fprintf(stdout, "Whoops, this is stdout");
return 0;
}
and corresponding NodeJS Code:
#!/usr/bin/env node
var exec = require('child_process').exec,
path = require('path');
var bin = path.join(__dirname, 'a.out');
var proc = exec(bin, function (error, stdout, stderr) {
console.log('stdout:', stdout);
console.log('stderr:', stderr);
});
proc.stdout.on('data', function (dat) { console.log(dat) });
and this is the output I get:
Whoops, this is stdout
stdout: Whoops, this is stdout
stderr: Whoops, this is stderr
Not sure why it would happen so in my code, May be because I am dumping a lot of information to stdout and stderr simultaneously or there is some buggy module I have included that may be causing this to happen. The actual code is quite big to be written here, but seems like I have to investigate where it might be going wrong.
I seem to have figured out the problem. The legacy C Code that dumps out the information was never referring to the FILE * being passed onto it. That was the reason all the information appeared on stdout and not on stderr. Fixed the API to take FILE * as an argument and dump out the information to correct FILE pointer and now it works.
I have a C file with several macros.
The exe generated from the file crashes several times reporting events in the Windows event viewer. Upon taking a dump of the process and analyzing it using WinDbg with the correct pdb files for the symbols, we get the stacktrace and know the function which is causing the problem.
The stacktrace shows the line number of our function code which called other functions one of which led to the crash-
08 msvcr80!fwrite(void * buffer = 0x00000000`01ded180, unsigned int64 size =
0x1fff38, unsigned int64 count = 0x524fe123, struct _iobuf * stream =
0x00000000`00000000)+0x5f [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\fwrite.c
# 77]
09 <function name>(void * param = 0x00000000`02d15a00)+0xb02
[<path to file> # 1516]
Our function called fwrite, which is shown to be at line 1516. However, there is no call to fwrite at 1516. (The crash happens because the stream argument to fwrite is 0x0)
I was wondering if these line numbers correspond to the source file after the macros are expanded ? What could be the reason for a possibly wrong line number ?
EDIT : The exe here is a debug build and was compiled with optimizations disabled.
I loaded the dump again in WinDbg but also linked in the source file to WinDbg itself this time. It points to line 1516 and upon viewing that in the source from WinDbg, it points to a line where there is no call to fwrite. However, there is such a call a few lines above.
Well i do not have direct answer to question here :(
But i would make a COD file. a file that maps source code to assembly code. Then see the assembly code generated for the function of interest. Specifically related to line 1516.
Am hoping that would give a fair insight as to whats going on behind the scene. You may want to give a quick try.
You just need to turn on a compiler flag to generate COD file. More can be read here
I have a function that pretty prints a data structure, its function prototype is:
void print_mode(FILE *fp, Mode *mode);
the FILE* allows you to redirect the output to anywhere you want, e.g. stdout, stderr, a file etc. Mode is the data structure
I am trying to call this function from within gdb and want the output to be directed to the gdb console window, stdout?
I have tried:
(gdb) p print_mode(STDOUT,fragment_mode)
No symbol "STDOUT" in current context.
(gdb) p print_mode(stdout,fragment_mode)
$17 = void
neither of which work
any ideas how i can get the output of the function to display in the gdb console?
should add - I am using gdb within emacs 24.2.1 under linux
STDOUT seems to be macro, which is not know to GDB, as handled prior to compilation by the pre-preprocessor.
Using stdout should do the job.
However the function print_mode() simply does not seem to print out anything.
In terms what's being printed to the console by the program being debugged, GDB's commands printand call should not make a difference.
For details on this you might like to read here: https://sourceware.org/gdb/onlinedocs/gdb/Calling.html
An issue might be that stdout by default is line buffered, so output would not occur before detecting a linefeed and print_mode() perhaps does not send a linefeed (\n).
To test this just use stderr as output file, as the latter isn't buffered:
p print_mode(stderr, fragment_mode)
Oh dear - silly mistake. You're right, stdout does do the job.
I forgot that having upgraded from emacs 23 to 24, the way gdb works has changed in as much as it now opens a separate buffer *input/output of program-name* to which it redirects the output of the program being debugged. In the prior version of emacs it was all displayed in the same, single gdb buffer.
So my second attempt was actually working, I was just looking in the wrong place so didn't see the output
If I were to create a driver, which, say hooks the windows function for opening a file. If in my driver I told the hook to printf("something"), when the driver is switched on and I opened a file, where would printf display the text to?
If you want to output text from a driver for debugging and experimental purposes, use DbgPrintEx. The output can be viewed via Sysinternals DebugView or a debugger.
printf is written to the stream stdout which is declared in stdio.h. It is opened the first time you touch one of the standard streams stdin, stdout, stderr. The standard streams stdin, stdout, and stderr are macros that call a stdio library function which opens the streams and returns an array those streams. The macro definitions index the array to get the right stream out. If the application has no console, the output goes to the "null" device.
You can view the debug output of your driver (compiled with debug config)
using DbgView
or WinDbg utility available on microsofts website
also to give print statements you could use following functions defined in wdm.h
DbgPrint(...)
DbgPrintEx(...)