Re: [Warzone-dev] How to read the exception dump?
Am Sonntag, 25. Februar 2007 schrieb Per Inge Mathisen: > I miss some documentation for the recently added exception handler. > Most importantly, how can I read the binary dump file? > > - Per > > PS Why not dump it as a text file? Now done. For further changes: The 1st (and 2nd) entry in the backtrace list should not be skipped, as it is afaik the only possibility to find out whether the given return addresses are valid for a given binary. (Just check whether addr2line of the 1st address matches the position of the call to backtrace() in lib/framework/exceptionhandler.c.) --Dennis pgpLHVrmGk3sD.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] How to read the exception dump?
Am Mittwoch, 28. Februar 2007 schrieb Dennis Schridde: > Am Montag, 26. Februar 2007 schrieb Dennis Schridde: > > Am Montag, 26. Februar 2007 schrieb Per Inge Mathisen: > > > On 2/26/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > > > I didn't do this yet, because backtrace_symbols(_fd) doesn't give > > > > more usefull output than backtrace until you compile with -rdynamic. > > > > > > Then why don't we? > > > > Don't what? Compile with -rdynamic? > > > > It seems to be the opposite of -fvisibility=hidden: > > -rdynamic > > Pass the flag -export-dynamic to the ELF linker, on targets that support > > it. This instructs the linker to add all symbols, not only used ones, to > > the dynamic symbol table. This option is needed for some uses of "dlopen" > > or to allow obtaining backtraces from within a program. > > > > Big symbol tables usually make the program load slower. Additionally this > > functionality can easily be reproduced with addr2line, so I don't see a > > reason to create any load on the user end. > > And just use some fancy compile switches so we can do something on the > > user end, which also could be done on the developer end easily, doesn't > > seem very good to me. > > > > > > There is an example which doesn't use any C runtime functions which may > > be unsafe: http://www.codeproject.com/debug/XCrashReportPt3.asp > > This is using the Windows API, though... > > Maybe there is something similar for Linux and MacOS, which we could > > utilize... > > > > > > For reading these binary blobs you need to tool I sent a while ago. I > > > > attached it again. > > > > > > This should definitely be in the repository if it is required to read > > > files produced by Warzone. In the tools/ directory, perhaps? > > > > K, I'll commit it. It can be deleted when we output plaintext files... > > Just looked into > http://www.unix.org/version3/ieee_std.html (the list of signal safe > functions is also included in the signal manpage). XSH / POSIX function standard -> chapter 02, 04 > > According to POSIX write() is signal safe, so we could use that instead of > fwrite() (which is not guaranteed to be safe). > We would have to write an own replacement of sprintf(), which doesn't use > malloc(), but that shouldn't be too difficult if we use a fixed string > length. > > --Dennis pgpzP6RbRjvQy.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] How to read the exception dump?
Am Montag, 26. Februar 2007 schrieb Dennis Schridde: > Am Montag, 26. Februar 2007 schrieb Per Inge Mathisen: > > On 2/26/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > > I didn't do this yet, because backtrace_symbols(_fd) doesn't give more > > > usefull output than backtrace until you compile with -rdynamic. > > > > Then why don't we? > > Don't what? Compile with -rdynamic? > > It seems to be the opposite of -fvisibility=hidden: > -rdynamic > Pass the flag -export-dynamic to the ELF linker, on targets that support > it. This instructs the linker to add all symbols, not only used ones, to > the dynamic symbol table. This option is needed for some uses of "dlopen" > or to allow obtaining backtraces from within a program. > > Big symbol tables usually make the program load slower. Additionally this > functionality can easily be reproduced with addr2line, so I don't see a > reason to create any load on the user end. > And just use some fancy compile switches so we can do something on the user > end, which also could be done on the developer end easily, doesn't seem > very good to me. > > > There is an example which doesn't use any C runtime functions which may be > unsafe: http://www.codeproject.com/debug/XCrashReportPt3.asp > This is using the Windows API, though... > Maybe there is something similar for Linux and MacOS, which we could > utilize... > > > > For reading these binary blobs you need to tool I sent a while ago. I > > > attached it again. > > > > This should definitely be in the repository if it is required to read > > files produced by Warzone. In the tools/ directory, perhaps? > > K, I'll commit it. It can be deleted when we output plaintext files... Just looked into http://www.unix.org/version3/ieee_std.html (the list of signal safe functions is also included in the signal manpage). According to POSIX write() is signal safe, so we could use that instead of fwrite() (which is not guaranteed to be safe). We would have to write an own replacement of sprintf(), which doesn't use malloc(), but that shouldn't be too difficult if we use a fixed string length. --Dennis pgpF6nLYyoHNn.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] How to read the exception dump?
Am Montag, 26. Februar 2007 schrieb Per Inge Mathisen: > On 2/26/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > I didn't do this yet, because backtrace_symbols(_fd) doesn't give more > > usefull output than backtrace until you compile with -rdynamic. > > Then why don't we? Don't what? Compile with -rdynamic? It seems to be the opposite of -fvisibility=hidden: -rdynamic Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of "dlopen" or to allow obtaining backtraces from within a program. Big symbol tables usually make the program load slower. Additionally this functionality can easily be reproduced with addr2line, so I don't see a reason to create any load on the user end. And just use some fancy compile switches so we can do something on the user end, which also could be done on the developer end easily, doesn't seem very good to me. There is an example which doesn't use any C runtime functions which may be unsafe: http://www.codeproject.com/debug/XCrashReportPt3.asp This is using the Windows API, though... Maybe there is something similar for Linux and MacOS, which we could utilize... > > For reading these binary blobs you need to tool I sent a while ago. I > > attached it again. > > This should definitely be in the repository if it is required to read > files produced by Warzone. In the tools/ directory, perhaps? K, I'll commit it. It can be deleted when we output plaintext files... pgp27d7YKrx1c.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] How to read the exception dump?
On 2/26/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: I didn't do this yet, because backtrace_symbols(_fd) doesn't give more usefull output than backtrace until you compile with -rdynamic. Then why don't we? For reading these binary blobs you need to tool I sent a while ago. I attached it again. This should definitely be in the repository if it is required to read files produced by Warzone. In the tools/ directory, perhaps? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] How to read the exception dump?
Am Sonntag, 25. Februar 2007 schrieb Per Inge Mathisen:
> I miss some documentation for the recently added exception handler.
> Most importantly, how can I read the binary dump file?
>
> - Per
>
> PS Why not dump it as a text file?
For Linux that's possible... Only problem is that printf and it's derivates
(which are probably needed to do properly formated output) are not in the
list of signal safe functions. But then, fwrite is not listed there, either.
I think we need to find out which functions are safe to use. Those are in
general functions which not use malloc.
I didn't do this yet, because backtrace_symbols(_fd) doesn't give more usefull
output than backtrace until you compile with -rdynamic.
For reading these binary blobs you need to tool I sent a while ago. I attached
it again.
The Windows minidumps can be examined using the MSVC debugger, the Windows
debugger windbg
(http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx) or the
Wine debugger winedbg.
--Dennis
#include
#include
#include
#include
#include
#include
#include
#include
uint32_t gdmpFormatVersion = 1;
int main(int argc, char * argv[])
{
void * btBuffer[128];
struct utsname sysInfo;
char * programName = NULL, * programVersion = NULL;
uint32_t btSize = 0, programNameSize = 0, programVersionSize = 0, signum = NSIG, validUname = 0, gdmpVersion = 0;
uint32_t sizeOfVoidP = 0, sizeOfUtsname = 0, sizeOfChar = 0;
if (argc != 3)
{
printf("USAGE: %s \n", argv[0]);
return EXIT_FAILURE;
}
char * dumpFileName = argv[1], addr2line[1] = {'\0'};
sprintf( addr2line, "addr2line -e %s ", argv[2]);
uint32_t addr2lineCommandLength = strlen(addr2line);
FILE * dumpFile = fopen(dumpFileName, "r");
if (!dumpFile)
{
printf("Could not open %s\n", dumpFileName);
return EXIT_FAILURE;
}
fread(&gdmpVersion, sizeof(uint32_t), 1, dumpFile);
if (gdmpVersion != gdmpFormatVersion)
{
printf("Unsupported gdmp version! Got: %u Expected: %u\n", gdmpVersion, gdmpFormatVersion);
return 1;
}
fread(&sizeOfChar, sizeof(uint32_t), 1, dumpFile);
fread(&sizeOfVoidP, sizeof(uint32_t), 1, dumpFile);
fread(&sizeOfUtsname, sizeof(uint32_t), 1, dumpFile);
fread(&validUname, sizeof(uint32_t), 1, dumpFile);
fread(&sysInfo, sizeOfUtsname, 1, dumpFile);
fread(&programNameSize, sizeof(uint32_t), 1, dumpFile);
programName = malloc(programNameSize*sizeOfChar);
fread(programName, sizeOfChar, programNameSize, dumpFile);
fread(&programVersionSize, sizeof(uint32_t), 1, dumpFile);
programVersion = malloc(programVersionSize*sizeOfChar);
fread(programVersion, sizeOfChar, programVersionSize, dumpFile);
fread(&signum, sizeof(uint32_t), 1, dumpFile);
fread(&btSize, sizeof(uint32_t), 1, dumpFile);
fread(&btBuffer, sizeOfVoidP, btSize, dumpFile);
fclose(dumpFile);
printf("Examining version %u gdmp...\n\n", gdmpVersion);
printf("Program name: %s\n", programName);
printf("Version: %s\n\n", programVersion);
if (!validUname)
printf("System information may be invalid!\n");
printf("Operating system: %s\n", sysInfo.sysname);
printf("Node name: %s\n", sysInfo.nodename);
printf("Release: %s\n", sysInfo.release);
printf("Version: %s\n", sysInfo.version);
printf("Machine: %s\n", sysInfo.machine);
printf("\nDump caused by signal: ");
switch(signum)
{
case SIGFPE:
printf("SIGFPE, Floating point exception\n");
break;
case SIGILL:
printf("SIGILL, Illegal instruction\n");
break;
case SIGSEGV:
printf("SIGSEGV, Segmentation fault\n");
break;
case SIGBUS:
printf("SIGBUS, Bus error\n");
break;
case SIGABRT:
printf("SIGABRT, Abort\n");
break;
case SIGTRAP:
printf("SIGTRAP, Debugger trap\n");
break;
case SIGSYS:
printf("SIGSYS, Bad system call\n");
break;
default:
printf("Unknown signal\n");
break;
}
printf("\nBacktrace:\n");
int i;
for(i = 0; i < btSize; i++)
{
printf("%#16x\n", btBuffer[i]);
sprintf(addr2line + addr2lineCommandLength + i*16, "%16x", btBuffer[i]);
}
printf("\nAt lines:\n");
system(addr2line);
free(programName);
free(programVersion);
return 0;
}
pgpgcWIfZMBsl.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] How to read the exception dump?
I miss some documentation for the recently added exception handler. Most importantly, how can I read the binary dump file? - Per PS Why not dump it as a text file? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
