Hopefully a VS C expert can help me.
I'm tinkering with Maverick and have a bug. However, it only shows up on certain occasions after a UCI "stop" command (e.g. when in analysis mode and stepping through a game). It also only happens when Maverick is running in a GUI (e.g. Fritz). The dialog simply says "abort has been called"
So my question is how can I figure out the line where there is an assert fail when the program is running in a GUI?
Thanks - Steve
OT: Finding the Line of the Assert Fail?
Moderators: hgm, Rebel, chrisw
-
- Posts: 1221
- Joined: Wed Mar 08, 2006 8:28 pm
- Location: Florida, USA
OT: Finding the Line of the Assert Fail?
http://www.chessprogramming.net - Maverick Chess Engine
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: OT: Finding the Line of the Assert Fail?
You can start an instance of Visual C++ and attach it to the process that is giving the assert (Attach to Process is on the Debug menu).
--Jon
--Jon
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: OT: Finding the Line of the Assert Fail?
Normally an assertion failure triggered through the assert() macro would cause an error message that contains source file and line number (__FILE__, __LINE__). But when running your program in a GUI you only get a MessageBox which unfortunately does not appear to show these details. I don't know a method to get this information displayed in that case.
Therefore attaching with a debugger seems to be the only way, as Jon stated.
To avoid this kind of annoying problem, but also to be able to set a breakpoint to the line where abort() is called (often I do not have the MSVC++ library source code at hand so I can't set a breakpoint into the code that implements the assert() macro!), I always use my own ASSERT() macro, and I define DEBUG in the debug version instead of defining NDEBUG in the release version. Example:
Of course using cerr << ... instead of fprintf() is fine here as well. Just don't make raiseAssertionFailure() a macro itself (which would be the same as doing fprintf + abort directly within ASSERT), it will bloat your code.
You can also use the _ASSERT or _ASSERTE macros but AFAIK these are Microsoft extensions so you lose portability.
Therefore attaching with a debugger seems to be the only way, as Jon stated.
To avoid this kind of annoying problem, but also to be able to set a breakpoint to the line where abort() is called (often I do not have the MSVC++ library source code at hand so I can't set a breakpoint into the code that implements the assert() macro!), I always use my own ASSERT() macro, and I define DEBUG in the debug version instead of defining NDEBUG in the release version. Example:
Code: Select all
// header file
#ifdef DEBUG
void raiseAssertionFailure(char const * file, int line, char const * expr);
#define ASSERT(expr) if (!(expr)) raiseAssertionFailure(__FILE__, __LINE__, #expr)
#else
#define ASSERT(expr)
#endif /* DEBUG */
// cpp file
#ifdef DEBUG
#include <cstdio>
#include <cstdlib>
#endif /* DEBUG */
#ifdef DEBUG
void raiseAssertionFailure(char const * file, int line, char const * expr)
{
fprintf(stderr, "*** ASSERTION FAILED: \"%s\" (%s, line %d)\n", expr, file, line);
abort();
}
#endif /* DEBUG */
You can also use the _ASSERT or _ASSERTE macros but AFAIK these are Microsoft extensions so you lose portability.
-
- Posts: 1221
- Joined: Wed Mar 08, 2006 8:28 pm
- Location: Florida, USA
Re: OT: Finding the Line of the Assert Fail?
Jon & Sven,
AWESOME!!
I've never attached to a process before. But it did the trick. I managed to find the bug in 5 mins.
Many thanks,
Steve
AWESOME!!
I've never attached to a process before. But it did the trick. I managed to find the bug in 5 mins.
Many thanks,
Steve
http://www.chessprogramming.net - Maverick Chess Engine
-
- Posts: 1600
- Joined: Mon Feb 21, 2011 9:48 am
Re: OT: Finding the Line of the Assert Fail?
Here's a good explanation.
Almost always the debug versions are problems in the GUI. Try the relase versión.
https://msdn.microsoft.com/en-us/library/k089yyh0.aspx
Almost always the debug versions are problems in the GUI. Try the relase versión.
https://msdn.microsoft.com/en-us/library/k089yyh0.aspx