4 ms·

Do you have QA running debug builds? In "release" builds, the asserts are compiled out. (Not sure what language and platform you're using) Or does QA switch to

by Tempest1981 3y ago

Do you have QA running debug builds? In "release" builds, the asserts are compiled out. (Not sure what language and platform you're using) Or does QA switch to release builds at some point? When asserts fail for QA, what do they see/collect?

flohofwoe 3y ago
> In "release" builds, the asserts are compiled out. That's just a convention, and IMHO not a good one. All the C++ games I helped shipping had asserts enabled in the release exe. We had our own custom assert macros, and different levels of assert checks (e.g. special "hot path asserts" were not included in release builds, but that was an exception and should be avoided - specifically, range-check asserts for array accesses were never removed since this was the most common source of problems). In general, the performance difference between keeping asserts in or removing them was mostly negligible (IIRC less than 2% in a typical frame), the only downside is that the executable becomes about 25% larger (and easier to reverse engineer) because of the embedded assert condition strings. This would have been solvable by replacing the assert strings with comptime hashes, but we didn't deem this important enough to implement). In addition, the custom asserts also generated a stack trace and a mini dump for easier post mortem debugging. > When asserts fail for QA, what do they see/collect? A MessageBox with: - the assert condition string - filename and line number of the assert - an optional printf-style programmer message (depending on the assert macro type) - the pretty-printed function/method name which contains the assert (very useful for generic code, e.g. you don't just see `Array<T>::push()` but also the resolved template parameters) - a stack trace (we generated a PDB file also for release builds to make the 'inhouse' stack traces human readable, but didn't ship the PDB to users - so stack traces for the shipped game would just display raw addresses, but those could be resolved on our side with the PDB we were storing for each release version - we wrote an extra inhouse tool for that) - plus a mini dump is written for post-mortem debugging, but with all the information above that was hardly ever needed for figuring out what the problem was The content of Windows MessageBoxes can be Copy-Pasted, and that's what QA was supposed to do when writing a ticket. PS: also important to note that we didn't use the C++ stdlib (with very few exceptions, like std::sort), e.g. most importantly we wrote our own container and string types).
- Tempest1981 3y ago
  Thanks for the details, sounds like a great setup. Any GitHub repos you can recommend? Except for writing your own stdlib. How long did that take? Was that to enhance bounds checking?
  - flohofwoe 3y ago
    It's all inhouse code unfortunately, and from a previous life :) What I still do in my open source libraries is to allow overriding the assert macro so that people can integrate their own assert implementation (along with allowing to override memory allocation). > Except for writing your own stdlib. How long did that take? Was that to enhance bounds checking? TBH the main reason was that I think the C++ stdlib APIs have terrible ergonomics. We modelled our container classes after C# containers and some common sense. Full control over memory allocation and asserts was just a side effect.

flohofwoe 3y ago

> In "release" builds, the asserts are compiled out. That's just a convention, and IMHO not a good one. All the C++ games I helped shipping had asserts enabled in the release exe. We had our own custom assert macros, and different levels of assert checks (e.g. special "hot path asserts" were not included in release builds, but that was an exception and should be avoided - specifically, range-check asserts for array accesses were never removed since this was the most common source of problems). In general, the performance difference between keeping asserts in or removing them was mostly negligible (IIRC less than 2% in a typical frame), the only downside is that the executable becomes about 25% larger (and easier to reverse engineer) because of the embedded assert condition strings. This would have been solvable by replacing the assert strings with comptime hashes, but we didn't deem this important enough to implement). In addition, the custom asserts also generated a stack trace and a mini dump for easier post mortem debugging. > When asserts fail for QA, what do they see/collect? A MessageBox with: - the assert condition string - filename and line number of the assert - an optional printf-style programmer message (depending on the assert macro type) - the pretty-printed function/method name which contains the assert (very useful for generic code, e.g. you don't just see `Array<T>::push()` but also the resolved template parameters) - a stack trace (we generated a PDB file also for release builds to make the 'inhouse' stack traces human readable, but didn't ship the PDB to users - so stack traces for the shipped game would just display raw addresses, but those could be resolved on our side with the PDB we were storing for each release version - we wrote an extra inhouse tool for that) - plus a mini dump is written for post-mortem debugging, but with all the information above that was hardly ever needed for figuring out what the problem was The content of Windows MessageBoxes can be Copy-Pasted, and that's what QA was supposed to do when writing a ticket. PS: also important to note that we didn't use the C++ stdlib (with very few exceptions, like std::sort), e.g. most importantly we wrote our own container and string types).

Tempest1981 3y ago
Thanks for the details, sounds like a great setup. Any GitHub repos you can recommend? Except for writing your own stdlib. How long did that take? Was that to enhance bounds checking?
- flohofwoe 3y ago
  It's all inhouse code unfortunately, and from a previous life :) What I still do in my open source libraries is to allow overriding the assert macro so that people can integrate their own assert implementation (along with allowing to override memory allocation). > Except for writing your own stdlib. How long did that take? Was that to enhance bounds checking? TBH the main reason was that I think the C++ stdlib APIs have terrible ergonomics. We modelled our container classes after C# containers and some common sense. Full control over memory allocation and asserts was just a side effect.