I am playing with the matrixmultiplication project downloadable from the bottom of the site:
http://blogs.msdn.com/b/nativeconcurrency/archive/2011/11/02/matrix-multiplication-sample.aspx
When I change the values of M, N, W from 256 to 4096, an unhandled exception is thrown:
Unhandled exception at 0x7630C42D in MatrixMultiplication.exe: Microsoft C++ exception: Concurrency::accelerator_view_removed at memory location 0x001CE2F0.
The console output is:
Using device: NVIDIA GeForce GT 640M
MatrixDiemnsion C(4096x4096) = A(4096x4096) * B(4096x4096)
CPU(single core) exec completed.
AMP Simple
The next statement to be executed is leaving the function mxm_amp_simple.
I am using VS2013 Ultimate on Windows 7 Professional N.
Why does this occur and how to prevent this from happening?
EDIT: I have found that the greatest value for M,N,W with which AMP Simple does not lead to a breakpoint being hit is 2800 (M=2800, N=2800, W=2800).
AMP Tiled on the other hand sometimes leads to a breakpoint, and in other cases executes correctly for M,N,W equal to 4096.
The exception is accompanied by a system error message:
"Display driver stopped responding and has recovered. Display driver NVIDIA Windows Kernel Mode Driver, Version 331.65 stopped responding and has successfully recovered."
In case someone else needs this.
This issue is most likely caused by Timeout Detection and Recovery (TDR). If kernel runs for more then 2 seconds windows will kill it and throw Concurrency::accelerator_view_removed exception. The easiest way to check this is to wrap code in try / catch bock. E.g.
try {
av_c.synchronize();
} catch (const Concurrency::accelerator_view_removed& e) {
printf("%s\n", e.what());
}
Microsoft has a blog post with more information, including pointers to instructions how to disable it.
Related
I have the problems with both SAVIHost v1.43 and VSTHost v1.57 for the case of Dexed 0.9.6. As I am a hobbist only, related to both MIDI and IT, I wish to ask some help to overcome these problems detailed below.
My problem with SAVIHost V1.43:
I copied savihost.exe (extracted from savihost3x64.zip) copied into directory "C:\Program Files\Common Files\VST3" (i.e. into the installation directory of Dexed.vst3) then renamed it to Dexed.exe, and launched this Dexed.exe.
I set "loopMIDI Port 1" (created prior by "loopMIDI v1.0.16 (27)") as "Input Port 1" via "Devices|MIDI..." and "1764 samples (25 b/s)" via "Devices|Wave...". (The sample rate was 44100 Hz, and both ports were "MME: Microsoft Sound Mapper).
Then I played some sounds by use of the virtual keyboard, and changed Dexed's programs (instruments) randomly - and Dexed seemed to work well, it played the different sounds with the actually selected instruments. Then I sent some MIDI Messages by Cakewalk by Bandlab to "loopMIDI 1"; Dexed produced the appropriate sounds, according to MIDI Note On/Off messages received - except that all the MIDI Program Change messages (C0 xx) were ignored.
Finally, when I clicked onto icon of Dexed.exe (i.e. renamed savihost.exe) in the Windows 10 Taskbar on the screen: the main window of Dexed.exe was minimized,
but when I clicked onto its icon again, although its main window is restored but crashed immediately. A dialog titled as "Dexed" appered,
containing an error message:
Unhandled exception 0xC0000005 at 00000014005BEBA
reading from FFFFFFFFFFFFFFFF
(followed by a list of the recent content of registers).
Furthermore, I noticed that resizing of window of Dexed.exe (moving its bottom edge upward) also causes a crash, but only after when Dexed.exe received some MIDI messages through "loopMIDI Port 1".
(i.e. playing on virtual keyboard, followed by similar resizing did not cause crashes - at least, I have not realized that.)
The situation was ditto for the case of SAVIHost V1.44 beta.
Problem with VSTHost V1.56 x64:
In the second case, I started VTSHost.exe, then loaded Dexed.vst3 via File|New Plugin... . Dexed.vst3 also seemed to work well at the beginning, i.e. while I played on the virtual keyboard bar, and changed the programs (instruments) and modified some parameters by the knobs on the screen. But when VSTHost received the first MIDI messages through the "loopMIDI Port 1", Dexed does not played any notes anymore. Instead, some extra message lines appeared in the dialog "Info" below the line "Chained as Insert before 1: Engine Output":
...
Processing is turned off (errors in PlugIn?)
ProcessReplacing
Exception 0xC0000005 at 000000014007ABF6 reading from 0000000000000000
...
Stack Trace:
...
Unfortunately, the situation was the same in case of VSTHost V1.57 beta x64.
Comments:
Dexed.vst3 worked without problems in case of other VST host apps (e.g. CakeWalk by BandLab and Cantabile 4 Lite), i.e. also the MIDI Program Change messages were executed properly.
(CakeWalk by Bandlab used Dexed.vst3 directly, Cantabile 4 Light received MIDI messages from CakeWalk by BandLab through "loopMIDI Port 1".)
similarly, the original standalone Dexed application also processed the MIDI Program Change messages through "loopMIDI Port 1" correctly.
version number of Dexed.vst3 reported as 1.0.0 by VSTHost (although is is originated from unzipping of "dexed-0.9.6-win.zip").
my PC has the followings:
-- OS: MS Windows 10, 22H2, build: 19045.2311 (x64)
-- CPU: Intel(R) Core(TM) i5-4460 CPU # 3.20GHz
-- RAM: 8 GB
-- motherboard: Gigabyte Technology Co., Ltd. B85M-D2V
-- sound: Realtek, High Definition Audio (on-board)
Finally, I wish to mention that I have tried other VSTs than Dexed's one with both SAVIHost and VSTHost: "sforzando.vst3" and "Roland Sound Canvas VA.dll".
There were no problem at all - no interception of any MIDI Message, no crash, etc -, they had been worked without any problem for hours. So I am not really sure, what and where are the root of the problems above: maybe in SAVIHost or VSTHost - or maybe in Dexed.
I wish ask some help, how I shall continue to determine, which component - ie. savihost/svthost or Dexed - is failed and resulted the problem?
Thank you very much for you kind efforts in advance!
I am trying to use the implementation of std::iostream provided by boost::asio on top of boost::asio::ip::tcp::socket. My code replicate almost line to line the example that is published in Boost Asio's documentation:
#include <iostream>
#include <stdexcept>
#include <boost/asio.hpp>
int main()
{
using boost::asio::ip::tcp;
try
{
boost::asio::io_service io_service;
tcp::endpoint endpoint(tcp::v4(), 8000);
tcp::acceptor acceptor(io_service, endpoint);
for (;;)
{
tcp::iostream stream; // <-- The exception is triggered on this line, on the second loop iteration.
boost::system::error_code error_code;
acceptor.accept(*stream.rdbuf(), error_code);
std::cout << stream.rdbuf() << std::flush;
}
}
catch (std::exception& exception)
{
std::cerr << exception.what() << std::endl;
}
return 0;
}
The only difference is the use I make of the resulting tcp::iostream: I forward everything I receive to the standard output.
When I compile this code with VisualStudio2019/toolset v142 and Boost from the NuGet boost-vc142, I get an Access Violation Exception only in the second iteration in the for loop, in the function
template <typename Service>
Service& service_registry::use_service(io_context& owner)
{
execution_context::service::key key;
init_key<Service>(key, 0);
factory_type factory = &service_registry::create<Service, io_context>;
return *static_cast<Service*>(do_use_service(key, factory, &owner));
} // <-- The debugger show the exception was raised on this line
in asio/detail/impl/service_registry.hpp. So the first iteration everything goes as planned, the connection is accepted, the data shows up on the standard output, and as soon as the stream is instanciated on the stack for the second time, the exception pops.
I don't have a high confidence in the accuracy of this location of the exception reported by the debugger. For some reason, the stack seams to be messed up and show only one frame.
If the declaration of stream is moved out of the loop, no exception is raised any more but then I need to stream.close() at the end of the loop, or nothing shows up on the standard output except the data from the first client's connection.
Basically, as soon as I try to instanciate more than one boost::asio::tcp::iostream (not necessarily at the same time), the exception is raised.
I tried the exact same code under linux (Arch linux, latest version of g++, same version of Boost) and everything works perfectly.
I could work around this issue by not using iostreams, but my idea is to feed the data received on the tcp socket to a parser which only accept implementations of std::iostream, hence I would still need to wrap asio's tcp socket in an homebrewed (and mediocre) implementation of std::iostream.
Does anybody have an idea on what's wrong with this setup, if I missed a crucial #define somewhere or anything?
Update:
Subsequent investigation show that the only situation where the access violation happens is when the executable is run from within Visual Studio (typ. from the menu Debug -> Start Debugging).
The build process seems to have no effect (calling directly cl.exe, using MSBuild, using devenv.exe).
Moreover, if the executable is run from a command prompt, and only then the debugger is attached, no access violation happens.
At this point, the issue is most likely not linked to the code itself.
Okay, it was exceedingly painful to test this on windows.
Of course I first tried on Linux (clang/gcc) and MingW 8.1 on windows.
Then I bit the bullet and jumped the hoops to get MSVC in command line with boost packages¹.
I cheated by manually copying the .lib/.dll for boost_{system,date_time,regex} into the working directory so the command line stayed "wieldy":
C:\work>C:\Users\sghee\Downloads\nuget.exe install boost_system-vc142
C:\work>C:\Users\sghee\Downloads\nuget.exe install boost_date_time-vc142
C:\work>C:\Users\sghee\Downloads\nuget.exe install boost_regex-vc142
(Be sure to get some coffee during those)
C:\work\> cl /EHsc test.cpp /I .\boost.1.72.0.0\lib\native\include /link
Now I can run test.exe
C:\work\> test.exe
And it listens fine, accepts connections (sequentially, not simultaneously). If you connect a second client while the first is still connected, it will be queued and be accepted only after the first disconnects. That's fine, because it's what you expect with the synchronous accept and loop.
I used Ncat.exe (from Nmap) to connect:
C:\Program Files (x86)\Nmap>.\ncat.exe localhost 8000
Quirk: The buffering was fine with the MSVC cl.exe build (linewise) as opposed to MingW behaviour, even though MingW also uses ws2_32.dll. #trivia
I know this doesn't "help", but maybe you can compare notes and see what is different with your system.
Video Of Test
¹ (that's a tough job without VS and also I - obviously - ran out of space, because 50GiB for a VM can't be enough right)
Environment: Visual Studio 2017, Windows 10 ver. 1709. Compiling mode: release.
When I call:
accelerator_view acc_view = accelerator().default_view;
an exception is raised (see figure link below), but the code performs fine afterwards.
But when the executable process exits and I call:
::GetExitCodeProcess(hChildProcess, &retVal);
from a caller process, instead of returning 0, it returns a garbage value in retVal.
Digging the source code, the problem seems to be in the snipped code below (SchedulerBase.cpp, line 149)
// Auto-reset event that is not signalled initially
m_hThrottlingEvent = platform::__CreateAutoResetEvent();
// Use a trampoline for UMS
if (!RegisterWaitForSingleObject(&m_hThrottlingWait, m_hThrottlingEvent, SchedulerBase::ThrottlerTrampoline, this, INFINITE, WT_EXECUTEDEFAULT))
{
throw scheduler_resource_allocation_error(HRESULT_FROM_WIN32(GetLastError()));
}
I think it is beyond my hands to fix it, because the code above is inside MFC. The same code works well when compiling with Visual Studio 2013. Refer to the figure attached of the stack, showing the raised exception (and catched inside) when I call
accelerator_view acc_view = accelerator().default_view;
The question: how to clean up the AMP before exiting and the getting the correct result when calling GetExitCodeProcess()?
Here is the figure:
Solved! If you add
concurrency::amp_uninitialize();
after using AMP framework, when the caller process calls
::GetExitCodeProcess(hChildProcess, &retVal);
The retVal parameter is filled correctly.
I am running the following MATLAB code on a system with one GTX 1080 and a K80 (with 2 GPUs)
delete(gcp('nocreate'));
parpool('local',2);
spmd
gpuDevice(labindex+1)
end
reset(gpuDevice(2))
reset(gpuDevice(3))
parfor i=1:100
SingleGPUMatlabCode(i);
end
The code runs for around a second. When I rerun the code after few seconds. I get the message:
Error using parallel.gpu.CUDADevice/reset
An unexpected error occurred during CUDA execution. The
CUDA error was:
unknown error
Error in CreateDictionary
reset(gpuDevice(2))
I tried increasing TdrDelay, but it did not help.
Something in your GPU code is causing an error on the device. Because the code is running asynchronously, this error is not picked up until the next synchronisation point, which is when you run the code again. I would need to see the contents of SingleGPUMatlabCode to know what that error might be. Perhaps there's an allocation failure or an out of bounds access. Errors that aren't correctly handled will get converted to 'unknown error' at the next CUDA operation.
Try adding wait(gpuDevice) inside the loop to identify when the error is occurring.
If either device 2 or 3 are the GTX1080, you may have discovered an issue with MATLAB's restricted support for the Pascal architecture. See https://www.mathworks.com/matlabcentral/answers/309235-can-i-use-my-nvidia-pascal-architecture-gpu-with-matlab-for-gpu-computing
If this is caused by the Windows timeout, you would see a several second screen blackout.
How can I set all exceptions behavior to pass to application and not appear in debugger?
I'm using IDA Pro 6.6 and WinDbg.
It's a bit awkward to do that for all exception types at once
.foreach(exc {sx}) {.catch{sxd ${exc}}}
What it does:
{sx}: list all exception types (and current settings, which you actually don't want)
exc: assign a variable
.foreach(...) {...}: cut it into pieces of single words and execute a command
sxd ${exc}: disable whatever is in variable exc
.catch{...}: ignore all the error messages which come from the settings information
The advantage of the above approach is that it is WinDbg version independent. If new exception codes are introduced, it will still work.
Processing of unwanted text can be avoided with PyKd. Save the following script into a file sdx.py and run !py sxd.py:
from pykd import *
sx = dbgCommand("sx")
for s in sx.splitlines():
ex = s[:4]
if not ex=="" or ex.isspace():
print("sxd "+ex)
dbgCommand("sxd "+ex)
Another option is processing all the exceptions manually:
.foreach(exc {.echo "ct et cpr epr ld ud ser ibp iml out av asrt aph bpe bpec eh clr clrn cce cc dm dbce gp ii ip dz iov ch hc lsq isc 3c svh sse ssec sbo sov vs vcpp wkd rto rtt wob wos *"}) {.catch{sxd ${exc}}}
However, if there are new exception codes in WinDbg, you have to add them to the .echo command.
In Windbg the sx family of commands is used to control how
exceptions should be handled.
For passing an exception directly to the application, use the sxd command which disable a specific exception.
(Actually disable mean ignore first chance exception)
To my knowledge, you must use sxd on all specific exceptions,
because sxd * means all exceptions that are not otherwise explicitly named.
Use the sx command to see the available exceptions and current settings. And use sxd on all you want to disable.
0:000> sx
ct - Create thread - ignore
et - Exit thread - ignore
cpr - Create process - ignore
<cut>
av - Access violation - break - not handled
0:000> sxd av
0:000> sx
ct - Create thread - ignore
et - Exit thread - ignore
<cut>
av - Access violation - second-chance break - not handled
The output is in my opinion a bit difficult to interpret; the av (access violation) will now not be handled by the debugger in any visible way.
The “Controlling Exceptions and Events” section in the help explains
the first chance and second-chance concept.
You can optionally control this from the WinDbg GUI 'Debug>Event Filters...' this will open a dialog box like so:
Here you can set how WinDbg handles each exception type and whether they should be enabled, disabled, outputted to the WinDbg console output or ignored and then on the event firing whether WinDbg or your app should handle it.
So in your case you can select 'Ignore' and 'Not Handled' there a MSDN page that explains a little more: https://msdn.microsoft.com/en-us/library/windows/hardware/ff541752(v=vs.85).aspx