Exception: No diagnostic information available.

[Julusian]

Current Behaviour

I am getting this a lot in the logs, often a few seconds apart. We used to get dropped-frames reported in the log and this seems to appear at the time the diag window reports dropped-frames so perhaps that is the cause?

Release builds appear to not show the stacktrace but do still show the exception heading line.

[2018-03-11 19:50:50.065] [error]   Exception: No diagnostic information available.

[2018-03-11 19:50:50.065] [error]    0# boost::stacktrace::basic_stacktrace<std::allocator<boost::stacktrace::frame> >::init at c:\code\casparcg22\build\packages\boost.1.66.0.0\lib\native\include\boost\stacktrace\stacktrace.hpp:81
[2018-03-11 19:50:50.065] [error]    1# boost::stacktrace::basic_stacktrace<std::allocator<boost::stacktrace::frame> >::basic_stacktrace<std::allocator<boost::stacktrace::frame> > at c:\code\casparcg22\build\packages\boost.1.66.0.0\lib\native\include\boost\stacktrace\stacktrace.hpp:130
[2018-03-11 19:50:50.065] [error]    2# caspar::log::get_stack_trace at c:\code\casparcg22\src\common\log.h:71
[2018-03-11 19:50:50.065] [error]    3# `<lambda_7ff54df2c81545b6e93b3c75c13a5f11>::operator()'::`1'::catch$33 at c:\code\casparcg22\src\core\video_channel.cpp:170
[2018-03-11 19:50:50.065] [error]    4# _C_specific_handler in VCRUNTIME140D
[2018-03-11 19:50:50.065] [error]    5# _BuildCatchObjectHelper in VCRUNTIME140D
[2018-03-11 19:50:50.065] [error]    6# RtlCaptureContext in ntdll
[2018-03-11 19:50:50.065] [error]    7# <lambda_7ff54df2c81545b6e93b3c75c13a5f11>::operator() at c:\code\casparcg22\src\core\video_channel.cpp:168
[2018-03-11 19:50:50.065] [error]    8# std::_Invoker_functor::_Call<<lambda_7ff54df2c81545b6e93b3c75c13a5f11> > at c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.13.26126\include\type_traits:16707566
[2018-03-11 19:50:50.065] [error]    9# std::invoke<<lambda_7ff54df2c81545b6e93b3c75c13a5f11> > at c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.13.26126\include\type_traits:16707566
[2018-03-11 19:50:50.065] [error]   10# std::_LaunchPad<std::unique_ptr<std::tuple<<lambda_7ff54df2c81545b6e93b3c75c13a5f11> >,std::default_delete<std::tuple<<lambda_7ff54df2c81545b6e93b3c75c13a5f11> > > > >::_Execute<0> at c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.13.26126\include\thr\xthread:241
[2018-03-11 19:50:50.065] [error]   11# std::_LaunchPad<std::unique_ptr<std::tuple<<lambda_7ff54df2c81545b6e93b3c75c13a5f11> >,std::default_delete<std::tuple<<lambda_7ff54df2c81545b6e93b3c75c13a5f11> > > > >::_Run at c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.13.26126\include\thr\xthread:247
[2018-03-11 19:50:50.065] [error]   12# std::_LaunchPad<std::unique_ptr<std::tuple<<lambda_7ff54df2c81545b6e93b3c75c13a5f11> >,std::default_delete<std::tuple<<lambda_7ff54df2c81545b6e93b3c75c13a5f11> > > > >::_Go at c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.13.26126\include\thr\xthread:233
[2018-03-11 19:50:50.065] [error]   13# std::_Pad::_Call_func at c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.13.26126\include\thr\xthread:211
[2018-03-11 19:50:50.065] [error]   14# register_onexit_function in ucrtbased
[2018-03-11 19:50:50.065] [error]   15# register_onexit_function in ucrtbased
[2018-03-11 19:50:50.065] [error]   16# BaseThreadInitThunk in KERNEL32
[2018-03-11 19:50:50.065] [error]   17# RtlUserThreadStart in ntdll
[2018-03-11 19:50:50.065] [error]   

Environment

• CasparCG Server version: c8d7047
• Operating system: Windows 10

[ronag]

This is weird. I've seen this as well. Wish we could have some more info.

[ronag]

If you are able to consistently reproduce it could you add more fine grained try/catch with CASPAR_LOG_CURRENT_EXCEPTION to try and nail down where it happens? Start from video_channel.cpp and split produce,mix, consumer and osc into separate try/catch sections.

[ronag]

Seems to come from the osc tick_ call

[ronag]

We should probably make sure osc run asynchronously from the channel. Instead of sync like it is today.

[ronag]

yea, I'm pretty convinced this is related to OSC... it's actually quite serious.

[ronag]

master should be a bit better now, the actual error isn't fixed but osc runs in a seperate thread so the impact should be lower. We still need help with reproducing & testing.

[ronag]

I think this doesn't happen in master anymore. We still need #928

[Julusian]

I suppose this issue has 2 parts.
The first which should be resolved is the frequency of appearance in the logs.
The second part is the very vague stacktrace and error. The stack trace looks to be to where the catch is located, rather than the throw.

This is another exception I am getting while looking at #773

[2018-03-16 17:03:36.459] [error]   OpenGL Error: 1282 Unknown error
[2018-03-16 17:03:36.459] [error]   Exception: Dynamic exception type: std::future_error
[2018-03-16 17:03:36.459] [error]   std::exception::what: std::future_error: No associated state
[2018-03-16 17:03:36.459] [error]   
[2018-03-16 17:03:36.459] [error]    0# caspar::log::get_stack_trace[abi:cxx11]() in bin/casparcg
[2018-03-16 17:03:36.459] [error]    1# caspar::core::video_channel::impl::impl(int, caspar::core::video_format_desc const&, std::unique_ptr<caspar::core::image_mixer, std::default_delete<caspar::core::image_mixer> >, std::function<void (caspar::core::monitor::state const&)>)::{lambda()#1}::operator()() const in bin/casparcg
[2018-03-16 17:03:36.459] [error]    2# 0x00007F8EA8E5A773 in /usr/lib/x86_64-linux-gnu/libstdc++.so.6
[2018-03-16 17:03:36.459] [error]    3# 0x00007F8EB10345AA in /lib/x86_64-linux-gnu/libpthread.so.0
[2018-03-16 17:03:36.459] [error]    4# clone in /lib/x86_64-linux-gnu/libc.so.6
[2018-03-16 17:03:36.459] [error]   

[ronag]

@Julusian that exception is unrelated here?

[ronag]

The second part is the very vague stacktrace and error. The stack trace looks to be to where the catch is located, rather than the throw.

Yes, only exceptions thrown by caspar will contain a stack trace.

[Julusian]

that exception is unrelated here?

My original intention with this issue was to do with the lack of useful stack trace, but that may not have been clear.

Yes, only exceptions thrown by caspar will contain a stack trace.

I think that exception is thrown by us on this line, so it should have a stacktrace surely? It appears that the first exception thrown here does, but after that they do not.

server/src/common/gl/gl_check.cpp

Lines 56 to 59 in b047f47

	case GL_INVALID_OPERATION:
	CASPAR_THROW_EXCEPTION(ogl_invalid_operation()
	<< msg_info("the specified operation is not allowed in the current state")
	<< error_info("GL_INVALID_OPERATION"));

[ronag]

The exception type is future_error. We don’t throw that.