I've been following this tutorial https://vulkan-tutorial.com/ to try and make a minecraft clone to learn how vulkan works. However, trying to create an ImageView results in "Access violation reading location 0x00000000000000F8" as can be seen here:
And here you can see that the vkCreateImageView function returns VK_SUCCESS
Initially I thought that the validation layer might be causing the exception, but removing the validation error leads to a "vector subscript out of range" error once the FrameBuffer creation tries to access the created ImageViews.
I have tried several things including: Having the VkImageView as a function variable and allocating it manually but they all result in the same Access Violation at 0x..F8. Compiling it in x86 just results in the Access Violation address changing to 0x000000A8.
I'm using the Vulkan SDK 1.0.65.1.
The Access Violation was being caused by MSI Afterburner / RivaTuner, stopping them makes the validation layers work properly again.
Source: https://vulkan-tutorial.com/FAQ
Related
ID3D12GraphicsCommandList& commandList = *com_ptr;
FLOAT values[4] = { 1,1,1,1 };
commandList.ClearUnorderedAccessViewFloat(m_gpuUavHandle, m_cpuUavHandle, m_resource.get(), values, 0, nullptr);
I'm getting the following runtime error:
Access violation reading location 0x0000000000000140
However, m_cpuUavHandle.ptr has value 326 which is only 6 bytes after the location of the access violation 320 (=140 in hexidecimal).
Since in Direct3d12 you manually calculate the handle address, it seems that there is room for something to go wrong
m_cpuUavHandle = CD3DX12_CPU_DESCRIPTOR_HANDLE(m_descriptorHeap.get()->GetCPUDescriptorHandleForHeapStart(), offset, m_cbvSrvUavDescriptorSize);
Edit:
I succeeded reproducing this in the DirectX 12 samples (and uploaded it to github) and this time got a debug message
D3D12 ERROR: ID3D12CommandList::ClearUnorderedAccessViewFloat: Specified descriptor handle ptr=0x0000000000000021 points to a descriptor heap type that is CPU write only, so reading it is invalid. UnorderedAccessViewCPUHandle is the issue. [ EXECUTION ERROR #646: INVALID_DESCRIPTOR_HANDLE]
Now m_cpuUavHandle.ptr=33 and the location of the access violation is at 32 (0x0000000000000020 in hexidecimal).
In my main project I think the exception is hit before the debug message is printed due to threading issues.
Now in my main project I'm getting
Access violation reading location 0x0000000000000000.
which is still six bytes before m_cpuUavHandle.ptr = 6, so I'm not sure if this is right
mateeeeee solved this in the comments. The docs specify that the cpu descriptor must refer to a non-shader visible heap (one created with D3D12_DESCRIPTOR_HEAP_FLAG_NONE).
For me the solution is to just have two identical CBV_SRV_UAV heaps one created with D3D12_DESCRIPTOR_HEAP_DESC::Flags = D3D12_DESCRIPTOR_HEAP_FLAG_NONE for calling ClearUnorderedAccessViewFloat and the other created with D3D12_DESCRIPTOR_HEAP_DESC::Flags = D3D12_DESCRIPTOR_HEAP_FLAG_SHADER_VISIBLE for everything else.
It is important to note that the cpu descriptor and gpu descriptor arguments for ClearUnorderedAccessViewFloat must come from different heaps.
I'm trying to write vtkImageData as a DICOM. I keep getting an "Access Reading Violation" when I try to write the image.
Unhandled exception at 0x00007FFDA30ECA50 : 0xC0000005: Access violation reading location 0x000001BD38D5C000
Here is my code:
vtkSmartPointer<vtkDICOMWriter> dcmWriter = vtkSmartPointer<vtkDICOMWriter>::New();
dcmWriter->SetInputData(testDat);
dcmWriter->SetFileName(fullPath.toStdString().c_str());
dcmWriter->Update(); // this line breaks
dcmWriter->Write();
testDat is a vtkSmartPointer<vtkImageData> type and has data in it. Any thoughts on whats causing the error? I can't find anything similar online.
I followed this example: https://github.com/dgobbi/vtk-dicom/blob/master/Examples/TestDICOMWriter.cxx
I don't have metadata, but that shouldn't be a problem.
I need to make some guesses here because you didn't post all of your code, but I suspect that the problem happens in the following line:
dcmWriter->SetFileName(fullPath.toStdString().c_str());
toStdString() is most probably returning a temporary std::string (fullPath looks like a Qt QString), on which you call c_str(). After the statement, your temporary is destroyed and whatever you have passed to SetFileName is now a dangling pointer. Hence the segfault.
Try the following instead::
const auto pathString = fullPath.toStdString();
dcmWriter->SetFileName(pathString.c_str());
This should hopefully work fine. Even if not, it definitely is an issue with your code.
These lines are from the example you posted:
writer->SetFilePrefix("/tmp");
writer->SetFilePattern("%s/IM-0001-%04.4d.dcm");
and you use
dcmWriter->SetFileName(fullPath.toStdString().c_str());
It seems that vtkDICOMWriter writes several files so you probably need to provide a file pattern. Anyway, it's hard to guess why it gives a reading error and it's hard to help if you don't post a full working example.
Last, vtkDICOMWriter is not a class from vtk, it was released separetely (it seems) in 2017. This means it's not tested against the rest of VTK at every new release.
I have looked around and have not found an answer to this, this is the offending line of code: d3d->GetImmediateContext()->IASetVertexBuffers(0, 1, &vertexBuffer, &stride, 0);
None of the passed in parameters are NULL(0x00000000)( The device context is also not null) but I still get an access violation error on every function call on the device context. The exception message I get is "Exception thrown at 0x00007FFDFD6CC796 (d3d11.dll) in 2D Platformer.exe: 0xC0000005: Access violation reading location 0x0000000000000000.". Again the weird thing is that it does this the next time I call any method on the device context, if I don't set the vertex buffer(Obviously nothing is drawn) then there is no crashes and I can call what ever I want.
Anyone else experienced a similar problem or does anyone have a suggestion of what could be causing this problem?
(If you need any clarification just ask)
I Figured out exactly what was wrong, it seems that I was passing in 0 for the offset which counted as a null pointer throwing the access violation error since the program obviously did not have access to the address 0x00000000. Also I thought it broke on the line after but it does break during the appropriate line and not the line after. So to fix this problem all I had to do was passing in a variable like this: &offset for the offset parameter and it worked
unsigned int offset = 0;
d3d->GetImmediateContext()->IASetVertexBuffers(0, 1, &vertexBuffer, &stride,&offset);
I hope that this helps someone else in the future.
I am following a tutorial for building a DX11Engine on youtube and I have become stuck. I am trying to render a sprite to the screen but when I try to run it I am getting
Access violation reading location 0x00000000".
The problem is occurring at the line:
result = device->CreateVertexShader(vertexShaderBuffer->GetBufferPointer(), vertexShaderBuffer->GetBufferSize(), NULL, &m_vertexShader);
Which is in Shader.cpp.
I have uploaded my code on to Git Hub https://github.com/nowayout2k/PJTS-CPP-DX11Engine . Thanks for your help in advance!
Access violation at 0x00000000 sounds like you accessed a null pointer. It is possible that you attempted to call a virtual method on it, thus the process attempted to read the virtual table pointer at the beginning of the object and failed, because it would be the zero address.
Make sure that the variables device and vertexShaderBuffer aren't null pointers. If they are, it could indicate that an error occured at the time of their initialization.
im having issues with MySQL++ and desperately need help.
I'm using Visual Studio 2010, MySQL++ v3.1.0 and MySQL v5.1.59( x86 & x64 );
All Library's have been compiled correctly. This error only occurs in Debug version due to the compiler setting "Both (/RTC1, equiv. to /RTCsu) (/RTC1)" being on.
Edit: I should note that this only happens in Debug version. In Release it works like a charm
I've tracked the problem back to the mysqlpp_d.dll, the MySQL++ object are crashing on there destructors due to reference counting. It complains about not being capable of accessing the memory of the ref counter, and when it tries to decrease it, it crashes. At least thats what I think happens.
I tried this to make sure everything gets derefrenced and removed in the correct order (even tho its irrelevant, but helped me track the true problem down I hope): http://pastebin.com/Ru0uYcy9
It crashes with:
First-chance exception at 0x000007feeef5dd4c (mysqlpp_d.dll) in Launcher.exe: 0xC0000005: Access violation writing location 0x000007feeeff5148.
Unhandled exception at 0x000007feeef5dd4c (mysqlpp_d.dll) in Launcher.exe: 0xC0000005: Access violation writing location 0x000007feeeff5148.
And breakes here:
http://pastebin.com/9Mfr7NwB
This code has a serious bug:
mysqlpp::UseQueryResult res;
{
mysqlpp::Query query = conn.query();
query << "SELECT USER();";
res = query.use();
row = res.fetch_row();
}
You aren't consuming all the result sets. In MySQL, stored procedures that return data return at least two separate result sets: the first is the results you asked for, and the second is status information about the call itself. See examples/multiquery.cpp in the MySQL++ source distribution for the correct way to handle this. Also see section 3.16 in the MySQL++ user manual.
The main consequence of this is that later queries on the same connection will fail.
I think your memory corruption is actually a secondary effect, and that the primary problem stems from ignoring the MySQL C API's attempts to tell you that you're trying to run two overlapping queries on the same connection, because you didn't consume the entire first result set. From what little code you've posted, I can see that you're ignoring returned error codes, so if you've also disabled MySQL++ exceptions, your code will completely ignore this error and blithely go on to stomp all over things it shouldn't.
By the way, please lose the trailing semicolon on the query. It isn't needed with the C API, and can cause confusion, especially in the face of multi-queries. Use semicolons only to separate multiple statements in a single query.