Though it may sound ridiculous, I am running localhost development environment on a computer with rather old Xeon processor, in Windows 7 , and noticed that from time to time, but quite regularly, the worker process died unexpectedly without reporting any problem. By attaching debugger to it, I found out that the culprit was the popcount instruction that the processor did not support. Since it is used only in the part dealing with NACKs, the error is tricky: it may look as if caused by some critical resource overload, although there is no any. (BTW, is this hardware requirement mentioned anywhere in the documentation?)
Anyway, there may be other hardware errors even in a modern setup. It would be helpful if mediasoup worker reported this kind of errors properly. In Windows, consider using structured exception handling pattern recommended by MS, e.g.:
int the_main(...)
{
try
{
}
catch (...)
{
}
}
int main(...)
{
__try
{
return the_main(...);
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
// GetExceptionCode() and report
}
}
I don’t like much the idea of adding this just for Window. Also, according to the doc you referenced:
When you use /EHs or /EHsc , the compiler assumes that exceptions can only occur at a throw statement or at a function call. This assumption allows the compiler to eliminate code for tracking the lifetime of many unwindable objects, which can significantly reduce code size. If you use /EHa , your executable image may be larger and slower, because the compiler doesn’t optimize try blocks as aggressively.
I don’t like much the idea of adding this just for Window.
What harm can it possibly do?
Also, according to the doc you referenced:
This is why synchronous and asynchronous exception handlers should be placed in different stack frames (i.e. nested functions for __try/__except and try/catch) - in this case it is not necessary to use /EHa, the structural exception handler is just added on top without any impact on the rest of the generated code.
What can we do with such a signal?
Log an error I believe, like it is done when regular С++ exceptions are caught. Currently, at least in Windows, the worker process dies silently in the middle of the packet processing, just like “now you see it, and now you don’t”.
, and noticed that from time to time, but quite regularly, the worker process died unexpectedly without reporting any problem. By attaching debugger to it, I found out that the culprit was the popcount instruction that the processor did not support. Since it is used only in the part dealing with NACKs, the error is tricky: it may look as if caused by some critical resource overload, although there is no any. (BTW, is this hardware requirement mentioned anywhere in the documentation?)