On 6/4/09, Dennis Schridde <devuran...@gmx.net> wrote:
> Am Donnerstag, 4. Juni 2009 19:33:00 schrieb bugina...@users.sourceforge.net:
>  > Revision: 7655
>  >
>  > http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7655&view=rev
>  > Author:   buginator
>  > Date:     2009-06-04 17:32:59 +0000 (Thu, 04 Jun 2009)
>  >
>  > Log Message:
>  > -----------
>  > Adding crash handler testing code. (to test crash dump reports)
>  > enable it by --crash on the command line.
>  Why do you hide a crashing path to display3d.c?
>  A simple *(char*)0=0; inside clparse.c would have worked, wouldn't it? Or if
>  that is for some reason not possible, add a dedicated function (with
>  significant name), which is called from an obvious location in main.c.
>  (I.e. if you need to initialise the game, then make --crash initiate that and
>  place the call after all init functions are passed and before the mainloop is
>  being started.)
>

Actually, that is by design, the 'bad ' crash report dumps are limited
to one or two lines (if at all) of the call stack, instead of having a
more deep call stack.
If we would crash right away, then it hasn't hit the main game loop or
anything of that nature.  So, no, I am not hiding it.  I just want it
in a area, that is deep enough in the codebase, so we can have several
layers of the call stack being shown.

This whole thing came about since we currently having no way to easily
verify which mingw setups work correctly, and which ones don't.  This
was the issue of a release we had in the past, where the crash dump
was worthless.
Some of the trunk nightly builds also have the worthless crash dumps.

This is a attempt for the packager to verify they can produce builds
that have proper crash dump support in them.

_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Reply via email to