Debug build used for release -> WebRTC crashes

[seriyvolk83]

Why this line is needed in build.sh?

sed -i '' 's/-ffile-compilation-dir/-fdebug-compilation-dir/g' ./build/config/compiler/BUILD.gn

The script builds Debug build for a release. As a result WebRTC crashes sometimes as follows:

Thread 21 name:  signaling_thread 0x0x106e11b00
Thread 21 Crashed:
0   WebRTC                                 0x105079608 rtc::Thread::ProcessMessages(int) + 132
1   WebRTC                                 0x1050795ec rtc::Thread::ProcessMessages(int) + 104
2   WebRTC                                 0x10507ab50 rtc::Thread::PreRun(void*) + 64
3   libsystem_pthread.dylib                0x236a2e9ac _pthread_start + 148
4   libsystem_pthread.dylib                0x236a2de68 thread_start + 8

because of

void ProcessMessages(StreamReader* stream, SessionData* session) {
...
 default:
         RTC_DCHECK_NOTREACHED(); // <-----------------------------

...
//https://chromium.googlesource.com/external/webrtc/+/master/rtc_base/checks.h

#define RTC_DCHECK_NOTREACHED() RTC_DCHECK(RTC_UNREACHABLE_CODE_HIT)

#define RTC_UNREACHABLE_CODE_HIT false

// The RTC_DCHECK macro is equivalent to RTC_CHECK except that it only generates
// code in debug builds. It does reference the condition parameter in all cases,
// though, so callers won't risk getting warnings about unused variables.
#if RTC_DCHECK_IS_ON
#define RTC_DCHECK(condition) RTC_CHECK(condition)
#endif

// If you for some reson need to know if DCHECKs are on, test the value of
// RTC_DCHECK_IS_ON. (Test its value, not if it's defined; it'll always be
// defined, to either a true or a false value.)
#if !defined(NDEBUG) || defined(DCHECK_ALWAYS_ON)
#define RTC_DCHECK_IS_ON 1
#else
#define RTC_DCHECK_IS_ON 0
#endif

// - RTC_CHECK(x) is an assertion that x is always true, and that if it isn't,
//   it's better to terminate the process than to continue. During development,
//   the reason that it's better to terminate might simply be that the error
//   handling code isn't in place yet; in production, the reason might be that
//   the author of the code truly believes that x will always be true, but that
//   they recognizes that if they are wrong, abrupt and unpleasant process
//   termination is still better than carrying on with the assumption violated.