This is used to differentiate LOG_ERROR (which is a *non* fatal error, but a error none the less) and fatal errors which result in program termination with no *visible* output (on windows/macs) on our end because of the crappy GUI functions so we usually dump it to stderr.txt and there is no clue that the program had to exit for whatever reason.
Hopefully, this will be helpful to windows people so they can differentiate between *our* exit/abort routines, and crashes that occur in drivers which look exactly the same since they get dumped back to the desktop with no visible clue why.
LOG_FATAL is *always* on in both debug & release builds.
On LOG_FATAL debug lines, on windows, we now throw up a modal dialog box with the current error message. At this time, this only happens when we have a error, and we use abort() right after the error, which makes it fatal.
That explains why this touches ~60 files :)
git-svn-id: https://warzone2100.svn.sourceforge.net/svnroot/warzone2100/trunk@8320 4a71c877-e1ca-e34f-864e-861f7616d084
Extension functions dealing with ...
* strings are in string_ext.h
* stdio (namely printf variants) are in stdio_ext.h
* math are in math_ext.h
These headers are no longer included by frame.h
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@6613 4a71c877-e1ca-e34f-864e-861f7616d084
- Don't ignore write(2)'s return value, instead handle it properly to deal with the cases where write(2) gets interrupted (by a signal) or returns prematurely because of non-blocking I/O
- Properly handle popen(3) returning NULL
* Don't assume the data written to stdout by "which" will just fit in our buffer
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@6577 4a71c877-e1ca-e34f-864e-861f7616d084
* Use C89 style variable declarations (i.e. at the beginning of scope-blocks)
* Use a proper set of #include paths
This should fix#160, patch by <i-NoD> slightly modified by me (moved variable declarations to the most local scope where used)
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@6385 4a71c877-e1ca-e34f-864e-861f7616d084
* use mkstemp(3) to create a temporary file that's guaranteed not to exist already
Prevents a potential symlink attack (e.g. where /tmp/warzone2100.gdmp is symlinked by user A to a file owned by user B, then having user B crash warzone)
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@6214 4a71c877-e1ca-e34f-864e-861f7616d084
Do this because we cannot trust malloc()'s heaps to be intact at the time an exception handler gets called.
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@6146 4a71c877-e1ca-e34f-864e-861f7616d084
* win32 Makefile system:
* Compile with debug symbols and all warnings enabled on both debug ''and'' non-debug builds
* Only use -Werror-implicit-function-declaration when compiling C sources, as for C++ implicit function declarations are illegal anyway (and g++ thus doesn't like this compiler option)
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@5647 4a71c877-e1ca-e34f-864e-861f7616d084
* Add a new function dbgDumpLog to dumpinfo.cpp for dumping the last debug messages
* Add a debug output callback to dumpinfo.cpp which is used to fetch the debug messages and store them in a ring buffer
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@5581 4a71c877-e1ca-e34f-864e-861f7616d084
* Flush the write end of the pipe after writing all GDB commands into it
* Process the return data (both return value and the contents of the output integer) from waitpid()
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@5390 4a71c877-e1ca-e34f-864e-861f7616d084
* return as soon as an error condition is detected, thus preventing the need for deep nested if-branches.
* Add some additional comments
* Return true or false, false indicating an error, true indicating success
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@5389 4a71c877-e1ca-e34f-864e-861f7616d084
* Instead compile that code on all platforms except for the given one (Mac OSX)
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@5385 4a71c877-e1ca-e34f-864e-861f7616d084
With our current backtrace dumps I quite oftenly find that in case of segfaults, which combined with assert failures are the most common crash cause, I cannot easily see what value the dereferenced pointer held.
To be able to see this the exception handler will now invoke the "disassemble" and "info registers" commands when producing a back trace using GDB. This gives us the ability to see the precise assembly instruction that triggered the crash, together with the value of the register that was used as pointer.
git-svn-id: svn+ssh://svn.gna.org/svn/warzone/trunk@5352 4a71c877-e1ca-e34f-864e-861f7616d084
Buginator
Per Inge Mathisen
Christian Ohm
Guangcong Luo
Giel van Schijndel
Freddie Witherden
Dennis Schridde
Roman C