The CHECK messages are really on the stack? They should definitely be getting stripped out of real builds.

They should be on the stack AFAIK (they weren't in the recent DCHECK build but that was intentional and being revisited --  issue 601469 ).

Could either be stripped server-side or sent in a crash-key by the client, whichever is easiest. I think Siggi was arguing to do as much work as possible client-side?

I meant I wouldn't expect any of those strings to be in an official build either way.

From a random sampling of one crash asserting on this line 

ATOM ClassRegistrar::RetrieveClassAtom(const ClassInfo& class_info) {
  ATOM atom = RegisterClassEx(&window_class);
...
  CHECK(atom) << GetLastError();
...

it appears that the check strings are indeed elided from the binary, and do not appear in the crash that I can find.

C:\>c:\src\tools\strings.exe c:\Users\siggi\Downloads\upload_file_minidump-6ef7a01400000000.dmp | findstr /i "atom"
kernel32.dllapi-ms-win-core-atoms-l1-1-0

If we go to the trouble of shipping another DCHECK build on Canary, however, perhaps we should make this happen for that build.

CHECK strings should be in all builds; *DCHECK* strings I would not expect to have present in Release builds, unless DCHECK_ALWAYS_ON was set.

Scott, it sounds like you're advocating that CHECK only includes the string-to-log in Debug builds, and omits it in Release builds?

I don't see any reason to ship a bunch of junk strings to users at all (isn't that the whole point of the crazy logging.h macros?), so I would expect that we don't ship any of those strings in official builds (CHECK or DCHECK). For one-off things it seems like it'd be useful and fine though.

No, CHECK strings are not in all builds, they're stipped in official builds (except on Android, sadly).

I see, are CHECK_OP strings also striped? I somehow recall using them in WinDBG but it might have been a local build..

Yes - official builds implement CHECK_OP via CHECK, which itself just
executes a debug break without logging anything.

I see then I guess the question is whether we need these strings in a crash key, sounds like they're too heavy to even compile in so I guess not... I'll archive this for now, @siggi feel free to re-open if you have more arguments in favor of doing this.