Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
Okay, so I am very new to Vulkan API, as seen in my last question. I am very confused about why vkCreateSwapchainKHR results in an access denied.
I have tried re-typing the code. I have tried Minimal Viable code. I have also tried initializing the swap chain at different times, but they all seem to not work.
The variables like _sur_capab are surface capabilities were got earlier than this. And, _logicalDevice was just an instance of VkDevice.
VkSwapchainCreateInfoKHR cri = { };
cri.clipped = VK_TRUE;
cri.oldSwapchain = VK_NULL_HANDLE;
cri.compositeAlpha = VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR;
cri.flags = VkSwapchainCreateFlagBitsKHR::VK_SWAPCHAIN_CREATE_FLAG_BITS_MAX_ENUM_KHR;
cri.imageArrayLayers = 1;
cri.imageColorSpace = VkColorSpaceKHR::VK_COLORSPACE_SRGB_NONLINEAR_KHR;
cri.imageExtent = _sur_capab.maxImageExtent;
cri.imageFormat = VkFormat::VK_FORMAT_ASTC_5x4_UNORM_BLOCK;
cri.imageSharingMode = VkSharingMode::VK_SHARING_MODE_MAX_ENUM;
cri.imageUsage = VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
cri.minImageCount = _sur_capab.minImageCount;
cri.sType = VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR;
cri.preTransform = _sur_capab.currentTransform;
vkCreateSwapchainKHR(
_logicalDevice,
&cri,
nullptr,
&_swapChain);
One advice up front: Always run your applications with the validation layers enabled, they should hint you at the potential problems in your code.
Without knowing the remaining relevant code parts, I can see several potential problems with your code above:
First one is the fact that you're setting invalid values for flags and imageSharingMode. The _MAX_ENUM_ values are not be used for initialization, so you need to pass proper values there. Usually it's 0 for the flags and e.g. VK_SHARING_MODE_EXCLUSIVE for the imageSharingMode. Check the specs to see what values are valid for the members of your VkSwapchainCreateInfoKHR structure.
Next up you need to check if the imageFormat you request is actually supported on your device via vkGetPhysicalDeviceSurfaceFormatsKHR. VK_FORMAT_ASTC_5x4_UNORM_BLOCK is a pretty specific format and I can imagine that only a very few, if any at all, implementations support this as a surface format.
It also looks like you're not setting the presentMode at all, making it 0 due to initialization, which equals to VK_PRESENT_MODE_IMMEDIATE_KHR. This mode may not be supported on your target implementation, just like the image format. You need to either select a present mode that's available everywhere, or properly select one that's supported via vkGetPhysicalDeviceSurfacePresentModesKHR.
Related
This is my first question ever posted, so please let me know if there is anything that needs changes in my post :)
I am currently working on a dialog that is supposed to let the user change the background-color for some signal plotting. The "wxColourPickerCtrl" seems to do exactly what I need. Since there are multiple plots/pictures to be manipulated, the ColourPickerCtrls are initialized in a loop with the chosen background color as the default value:
for (const auto& [signalName, signalProperties] : properties)
{
wxColourPickerCtrl* selectBackgroundColor = new wxColourPickerCtrl(this, signalProperties.first, signalProperties.second.backgroundColor, wxDefaultPosition, wxDefaultSize);
}
"this" is an object of type SignalPropertiesDialog, which is directly inherited from wxDialog.
I have left out all the necessary sizer stuff, since it's not relevant for the problem (at least imo). "properties" is structured as follows:
std::map<std::string, std::pair<int, GraphPicture::Properties>> signalProperties_;
where GraphPicture::Properties contains the properties I want to manipulate:
struct Properties
{
wxColour backgroundColor{ *wxWHITE };
wxColour lineColor{ *wxBLACK };
int linewidth_px{ 1 };
bool isShown{ true };
};
The application successfully builds but immediately crashes on startup while generating those color picker objects.
wxIshiko has uploaded multiple tutorials and code snippets as examples for various wxWidgets controls, including the wxColourPickerCtrl. So I downloaded the sample code and tried to run it. Surprisingly, it worked.
While running through the code step by step I noticed the following difference:
The wxColourPickerCtrl is based on wxPickerBase. The wxPickerBase is created by calling the constructor of wxColourPickerCtrl (what I am actually doing in my code). During the construction of the wxPickerBase, the desired color is called by the name wxColourDataBase::FindName(const wxColour& color) const where the wxColourBase itself is instantiated. This is where the difference is:
When running the code snippet by wxIshiko, wxColourDataBase is instantiated correctly including the member m_map of type wxStringToColourHashMap* which is set to be NULL.
When running the code written by myself, wxColourDataBase is not correctly instantiated, and thus the member m_map is not set to be NULL, which leads to to the crash.
I have the feeling that there is nothing wrong with the way I set up the wxColourPickerCtrls. I somehow think there is a difference in the solution properties of the projects. I checked those but was not able to find any relevant differences.
I would really appreciate any hint or help since I am completely stuck on that problem.
Thank you very much in advance and have a good one,
Alex
EDIT:
I attached a screeny of the call stack.
Call stack
When does this code run exactly? If it is done after the library initialization (which would be the case, for example, for any code executed in your overridden wxApp::OnInit()), then wxTheColourDatabase really should be already initialized and what you observe should be impossible, i.e. if it happens it means that something is seriously wrong with your library build (e.g. it doesn't match the compiler options used when compiling your applications).
As always with such "impossible" bugs, starting with a known working code and doing bisection by copying parts of your code into the working version until it stops working will usually end up by finding a bug in your code.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
I have been trying to find a way to enforce unique error messages in our application. That is, I want to know exactly which line of code produced the error, so when users contact support we know the source of the error from the message logged.
I found this question which gave me a mechanism (using guids to enforce uniqueness), but one question remains: How do I prevent copy/paste duplication? - specifically, a developer copying the logging line itself:
Log(<guid>, errorMessage);
In this case the guid would be duplicated and no longer useful for identifying the unique line which generated the error.
The one idea I have had which would actually work is writing a tool to be run by our build server which would parse the code for error message guids, keep a list, and fail the build on a duplicate. I'm wondering if there is a cleaner solution.
Other things I've considered:
There are various ideas using some sort of central listing of error messages, but I have not found one which addresses the copy/paste issue.
There are also a number of schemes which would require keeping a manual list in some way. I don't want to pursue something like this as it creates the possibility of discrepancies between the list & production code.
I've also seen suggestions to use the stack trace, but I'm a bit hesitant to do that for security & performance reasons.
I don't know if this is really what you're looking for, but you can include the file, method, line number (and other things) in your log message without needing a unique number that you would later search the source code for if you make use of the System.Diagnostics.StackTrace class. This way, even if there's a copy/paste violation, you still know exactly where the call to Log came from.
Here's a simplified example that returns the file name, method signature, and line number of a stack trace item. Note that this code finds the stack trace item for a call to the "Log" method and returns the next one. That will be more clear shortly:
using System.Diagnostics; // Needed for the StackTrace class
private static string GetStackTraceInfo()
{
var stackTrace = new StackTrace(true).GetFrames();
// Find the item just after the call to teh 'Log' method:
var item = stackTrace?
.SkipWhile(st => !st.GetMethod().Name.Equals("Log"))
.Skip(1)
.FirstOrDefault();
return item == null
? string.Empty
: string.Format("{0} => {1}, line #{2}", Path.GetFileName(item.GetFileName()),
item.GetMethod(), item.GetFileLineNumber());
}
Here's the Log method that enforces the stack trace info added to a log (and this is the method name that we were searching for in the code above):
private static void Log(int id, string message)
{
Console.WriteLine($"Error #{id}: {message} ({GetStackTraceInfo()})");
}
And an example usage:
private static void Main()
{
DoSomething();
DoSomethingElse();
GetKeyFromUser("\nDone! Press any key to exit...");
}
private static void DoSomething()
{
Log(1000, "I copied/pasted this error message from somewhere!");
}
private static void DoSomethingElse()
{
Log(1000, "I copied/pasted this error message from somewhere!");
}
Output
I have an IP camera that receives commands using POST HTTP requests(for example to call PTZ commands or set various camera settings). The standard way of controlling it is through it's own web interface which is partially an ActiveX plugin and partially standard html+js. Of course because of the ActiveX part it only works in IE under Windows.
I'm attempting to change that by figuring out all the commands and writing a small python or javascript code to do the same, so that it is more cross platform.
I have one major problem. Each POST request contains a calculated "cc" field which I assume is a checksum. The JS code in the cam interface points out that it is calculated by calling a function inside the plugin:
tt = new Date().Format("yyyyMMddhhmmss");
jo_header["tt"] = tt;
if (getCpPlugin() != null && getCpPlugin().valid) {
jo_header["cc"] = getCpPlugin().nsstpGetCC(tt, session_id);
}
nsstpGetCC function obviously calculates the checksum from two parameters the timestamp and session_id. Real example(captured with Wireshark):
tt = "20171018231918"
session_id = "30303532646561302D623434612D3131"
cc = "849e586524385e1071caa4023a3df75401e5bb82"
Checksum seems to be 160bit. I tried both sha-1 and ripemd-160 and all combinations of concatenating tt and session_id I could think of. But I can't seem to get the same hash as the one the original plugin gets. The plugin dll seems to be written in c++. And I have almost no experience with decompilation to dive into this problem from that angle.
So my question basically is can someone figure out how they calculated that cc, or at least give me an idea in which direction to research further. Maybe I'm looking at wrong hash algorithms or something... Or give me some idea how I could somehow figure out what the original ActiveX function nsstpGetCC is doing for example by decompilation or maybe by monitoring it's operation in memory while running. What tools should I use?
I'm experiencing an issue ussing Drawcell on a TStringGrid with C++ Buidler XE4.
In a portion of my C++ code i put some text in cells like in the folowing lines:
StringGrid1->Cells[x][y] = "1.0";
And in the DrawCell Event when i do this :
UnicodeString tmp = StringGrid1->Cells[ACol][ARow];
tmp is "1" (when ACol = x and ARow = y). i am sure that nowhere in my code i replace the "1.0" in "1". So if anybody could explain me what's happen i will be very gracefull.
As i Experiment sometimes it work's and sometimes not (when recompiled).
Are the lower strats of C++Builder (which are delphi ones) sometimes swap (or something like that) the StringGrid behind the TStringGrid?
What you describe cannot be reproduced. The TStringGrid control is know to work well. If you put a string into a cell, that same cell will come back until you modify it.
Most likely there is something else in your program that is modifying this. In order for you to track this down I suggest that you make an SSCCE. Once you do so you'll surely find the reason for your confusion.
So I'm trying to make use of a GtkSourceView in C++ using GtkSourceViewmm, whose documentation and level of support give me the impression that it hasn't been very carefully looked at in a long time. But I'm always an optimist :)
I'm trying to add a SourceView using some code similar to the following:
Glib::RefPtr<gtksourceview::SourceLanguageManager> source_language_manager = gtksourceview::SourceLanguageManager::create();
Glib::RefPtr<gtksourceview::SourceLanguage> source_language = Glib::wrap(gtk_source_language_manager_guess_language(source_language_manager->gobj(), file, NULL));
Glib::RefPtr<gtksourceview::SourceBuffer> source_buffer = gtksourceview::SourceBuffer::create(source_language);
gtksourceview::SourceView* = m_source_view = new gtksourceview::SourceView(source_buffer);
m_vbox.pack_start(*m_source_view);
Unfortunately, it spits out the warning
(algoviz:4992): glibmm-WARNING **:
Failed to wrap object of type
'GtkSourceLanguage'. Hint: this error
is commonly caused by failing to call
a library init() function.
and when I look at it in a debugger, indeed the second line above (the one with the Glib::wrap()) is returning NULL. I have no idea why this is, but I tried to heed the warning by adding Glib::init() to the begining of the program, but that didn't seem to help at all either.
I've tried Google'ing around, but have been unsuccessful. Does anyone know what Glib wants me to init in order to be able to make that wrap call? Or, even better, does anyone know of any working sample code that uses GtkSourceViewmm (not just regular GtkSourceView)? I haven't been able to find any actual sample code, not even on Google Code Search.
Thanks!
It turns out, perhaps not surprisingly, that what I needed to init was:
gtksourceview::init();
After this, I ran into another problem with one of the parameter to gtksourceview::SourceLanguageManager, but this was caused by a genuine bug which I subsequently reported and was promptly fixed. So everything's working great now!
I use gtkmm. Typically you have to initialize things with something like :
_GTKMain = new Gtk::Main(0, 0, false);
Of course do not forget :
delete _GTKMain;
Check here for details :
http://library.gnome.org/devel/gtkmm/2.19/classGtk_1_1Main.html
(Sorry but the link option does not work ...)