I have a set of CIL code that is not working as expected. My question is, Is there a way to inspect or peek the evaluation stack at any point?
Thanks
Related
I'm implementing a basic textured cube example, and have run into an interesting problem - after passing my DescriptorWriteSet structure to the UpdateDescriptorSets API call, all of the fields have been zeroed out. Any code which tries to read the fields after that gets a null pointer exception (because the DescriptorBufferInfo pointer is now null). This only happens when VK_LAYER_LUNARG_core_validation is enabled, and if I disable it, the API call seems to work fine.
My sample is incomplete, so I can't say whether it works with the layer disabled, or if I have some error in my code. However, I have been staring at the values being passed in to this call, doing a sanity check, because I was certain I wasn't passing in a null pointer. Is this a bug, or is this expected behaviour?
Windows 10
LunarG SDK 1.0.8 (I'd like to be on 1.0.13, but that requires the newer AMD driver, which blue screens my computer)
EDIT:
It's not just zeroing out the structure I give it - I'm currently passing in only the first DescriptorWriteSet in a constant array, and it's zeroing the second as well. In fact, when I inspect the memory around the array, this layer is touching memory on either side of the array. This seems a lot more like a bug to me...
EDIT 2:
It turns out the problem stemmed from my code:
DescriptorSetLayoutBinding layout_bindings[]{
DescriptorSetLayoutBinding()
.Binding(0)
.Descriptors(DescriptorType::UNIFORM_BUFFER, 1)
.StageFlags(ShaderStageFlagBits::VERTEX),
DescriptorSetLayoutBinding()
.Binding(0)
.Descriptors(DescriptorType::COMBINED_IMAGE_SAMPLER, 1)
.StageFlags(ShaderStageFlagBits::FRAGMENT)
};
Both my layout bindings had the same binding index of 0. Of course, I would expect this to cause problems, but I would not expect this to cause the zeroing of structures passed in future API calls... I'm always hesitant to raise things like this as issues on Github, because more than half the time it's my fault that I'm getting the issue.
The VK_LAYER_LUNARG_core_validation layer should not be modifying the structure pointed to by pDescriptorWrites in the vkUpdateDescriptorSets. If you think it is doing this modification of the structure passed in, please post issue, along with repo case, to https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues.
I am calling a ASYNC method in an MVC4 application. This method has to call a dozen or so other methods, which are nested. My issue is that if any of these nested methods break, it passes the error to the parent method. Since they are all nested, it just keeps passing up the chain returning to the HTTP context the generic error message.
Since I have so many nested methods, I have no clue how to find more information on the error. Even a simple line that broke would be extremely helpful.
Right now I am resorting to breaking every line to see which ran last before it stop responding. This Method alone, with it's nested methods, are over 2000 lines of code. As you can tell, this is a very un-effective way at debugging.
Any help at a better way of finding out where a ASYNC method actually broke, when in nested methods, would be extremely helpful. I really want to avoid doing a Try/Catch on every method I have.
-- Edit --
This has been answered. I put my solution below and will mark it as answered in two days, per StackOverflow restrictions.
Apparently if I put a Try/Catch on the first call inside my Action Method it at least gives me the line in the stack trace. Once noting this, I added ELMAH and inspected my error log when throwing a generic exception. It appears that the line gets passed back to ELMAH also.
While this is not nearly as nice as normal exception breaking in visual studio, it allows me to easily put a breakpoint on that exact line to see what is happening.
Unfortunately, asynchronous "stack traces" do not work very well out of the box.
You can do your own tracing using a technique I describe in this blog post. Or you could try installing my async diagnostics package which adds the asynchronous "stack trace" to the exception's Data property (note: not logged by default in ELMAH). However, this package is not yet production-ready, so I recommend uninstalling before deploying.
I have this situation where an EXE program imports a DLL for a single function call. It works by passing in a custom structure and returning a different custom structure. Up till now it's worked fine until I wanted one of the structs data members to be a vector < MyStruct >
When I do a sizeof(vector< MyStruct >) in my program I get a size of 20 but when I do it from inside the DLL I get a size of 24. This size inconsistency is causing a ESP pointer error.
Can anyone tell me why a Vector < MyStruct > would be a different size in the DLL than in the program?
I have reverified that my structs in both the DLL and the Program are identical.
I would appreciate any help on the subject. Thank you.
I meet similar issue when the class has a vector<..> member, and with an inline construct function(implemented in header file).
No matter DLL is release or dll version, as if as EXE is release version, size of that class calculated in EXE is 3 byte less than in DLL, thus the stack will be destroyed.
This problem can be fixed by one of below change:
It's only occured with VC98(SP6). Change to VS2008, issue disappears.
Move the inline construct function to CPP file, issue disappears
too.
I hope someone can help to give a more detailed explanation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Okay, so I've got a .NET console application with it's Main method, contained in a Program class. You know, the usual:
class Program
{
static void Main(string[] args)
{
// Do something spectactular
}
}
Since I've started using StyleCop and FxCop so rigorously, I've become kind of nit-picky about making sure everything is properly documented.
Then it hit me. I have absolutely no idea how to properly document Program and Program.Main.
I suppose, in the long run, that you could go with the following:
/// <summary>
/// Encapsulates the application's main entry point.
/// </summary>
class Program
{
/// <summary>
/// The application's main entry point.
/// </summary>
static void Main(string[] args)
{
// Do something spectactular
}
}
But that seems woefully inadequate (despite the fact that my Main routines always delegate to other classes to do the work).
How do you folks document these things? Is there a recommendation or standard?
In my humble opinion, it's not worth the trouble to document the main function, especially if you are just going to say "The application's main entry point." If someone doesn't know that Main is the application's main entry point, you don't want them anywhere near your code :-)
If you were to put anything there, you might document what the expected or accepted arguments are, but I think there are better places to document program options (like, a usage function that prints usage, the users manual, a readme file, or elsewhere), since that information is useful not only to developers but also to users of the software.
Documentation is there to add something that's not obvious from the code. And tools are there to help you, not to dictate you what should and should not be documented.
"The application's main entry point" does not add anything, so don't write it.
If there's anything non-obvious like parameters, document this.
Add documentation at the class level that describes what the console program actually does, so it's purpose.
In the Main method, document the required arguments etc., unless if you hand that off, 'main entry point' does suffice.
I tend to hand it off to an instance method in Program called Run(string[] args), so in that case, document the Run method with the arguments/switches options.
The body of my Main() method then simply looks like:
Program prog = new Program();
prog.Run(args);
Don't, just don't.
Just look at those 2 samples you created and compare which is more readable?
I'll bet you'll choose the one without comments.
I'm trying to use a COM library that makes use of a vtable. However, something funky is going on with the stack after I call the functions, which tells me I'm doing something wrong.
The header file with the vtable definition is pasted here: pastebin.com/m2d66c18c (see in particular the code starting at line 810). An example is pasted here: pastebin.com/m1b46e662.
The table is being filled with the correct locations for the functions, but when I call the function(s), they appear to be looking in the wrong locations for the arguments on the stack. Also, after calling the functions in the table, the stack is messed up and my program crashes. I've tried changing the function type to both __cdecl and __stdcall but this does nothing.
It's either my code or the library, and the company that wrote the library hasn't gotten back to me -- because it's the weekend, I'm assuming. Also, there is a demo application that utilizes the library, and it works -- so I think it's my code/compiler (gcc)/something else, not the library.
Could it be that there something in particular that you need to do in order to use a COM library?