How to access the call stack of a DOORS DXL script? - assert

In order to write a proper assert(bool) function for testing my DXL programs, I would love to be able to print the call stack if the boolean is false.
Can anybody help me with either getting access to the call stack or finding a handy assertion function?

There really isn't a lot of information regarding this type of debugging available in DXL. I have seen some 3rd party DXL Compilers on the market (Sodius makes a good one) that might help or you can try to write your own debug using the information in the Error handling section of the DXL Reference Manual.

Related

glDebugMessageCallback more detailed information

Everywhere I read that glDebugMessageCallback is the better solution to get errors, so I implemented it. So far so good. And I am getting indeed more detailed information about what's going on. Currently on NVIDIA it looks f.e. like this:
DebugLog: In source API, type OTHER, id 131185, severity : NONE,
message Buffer detailed info: Buffer object 3 (bound to
GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0), and
GL_ARRAY_BUFFER_ARB, usage hint is GL_STREAM_DRAW) will use VIDEO
memory as the source for buffer object operations.
Really nice, indeed- however, I miss one thing- I can't indicate here where exactly this happened.
If I use old style method with a macro like this:
#define CHECK_GL_ERROR() CheckGLError(__FILE__, __LINE__)
and
glGetError()
it's far less detailed and a mess in the code- BUT! I can track it more easily down to the line or call it happened, at least when debugging myself.
Of course, if I reduce the log level to something more severe, it is probably also easier to identify the origin, since there are less functions in question, yet, depending on code I find this a bit imprecise to find a specific function.
So my question is now- is there a way to tell what exactly the callback triggered, the function or the perhaps the line in the code, like in the old method (that is, now without adding a manual breakpoint/debug)??
I would find that very handy, especially when considering a situation in which someone who is maybe just using the software could provide me a log only for a problem I can't reproduce myself.
PS: Could someone enlighten me what "id" is for? I found a lot of tutorials and explanations, also read the docs but I still don't see of what use it is for debugging.
There are two ways that help you identify where the error comes from:
First, you can glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS) to ensure that errors are thrown in the scope of the function that produces them. When you now set a breakpoint in the error callback function, you'll see through the callstack where the error originates.
Second: OpenGL allows you to associate names and scopes with each OpenGL object. This allows you to specify names for, let's say, a buffer. Have a look here for more details.

How to print the contents of an array without creating anything on the stack?

I was asked this question in an interview. I didn't know what to tell him. I asked him what's the solution but he refused to answer. I searched for it on google and I couldn't find it. Appreciate the help.
I beleive, that this question was intended more to check your understanding of internal program working (stack usage, allocation/deallocation, etc). Lets consider your question:
How to print the contents of an array without creating anything on the
stack?
What exactly that means? Should the program stack be in the same state after printing? In that case just use a function to print stack contents, it will return the stack to the same state. If your interviewer means, that there should be no changes on the stack altogether, it is very difficult, and perhaps not possible on many platforms. This requirement means, that you could not use any printing function from the standard C/C++ library, because any call will alter the stack. You could create working code, that will not affect stack memory in the some older OS (like MS DOS for example) by the direct writing to the video buffer, using only the procesor registers. Any modern OS will prevent that and would require some API call, which will make initial requirement quite impossible.
Option 1 : Interviewer was an idiot
Option 2 : Question was a test of character.
I always like to ask an "impossible" question to see if the interviewee will try of B.S. me or if they will admit they don't know and that they would try to find the answer and ask for help if need be

how to control one program from other

I want a little help. I know java and little c++. I have seen trainers for games which can set health of player and spawn cars etc. I want to make something similar to that.
For example we have minesweeper running. when i run my java program and click on a button it should call minesweepers function and minesweeper game should show that i won.
So my question is how to establish a connection or something to another program running and calling the program's functions by passing arguments. how is it possible. I heard about reverse engineering and downloaded a program called OllyDBG. And a winject dll injector. i donot know what to do. Combining all these how can i make a program. Please give me ideas or codes or resources helpful.
First you need to reverse-engineer minesweeper to find out the memory location of different variables. Remember that you will probably not be able to run minesweeper's functions due to context, but you can inject code on it to run those. You can read memory easily, though.
To inject code, you must assemble it separately, and then write it in the process virtual space.
In windows API there are several functions that allow opening a process and accessing it memory, but you must have privileges for that.
In summary: To do that, the first thing you need to learn is how to disassemble and understand a program. Only then youll figure out how easy minesweeper is to understand.
BTW: minesweeper stores the map raw in memory. A simple memory inspector will allow you to get the map of it.
Well, your starting sentence was:
"I have seen trainers for games which can set health of player and spawn cars etc. I want to make something similar to that."
Here's a very nice reference code that does what you talked about in C++
http://www.codeproject.com/Articles/7468/Game-Wizard
First strengthen your C++ skills and then study what he does there.
A general description would be that the "victim" process memory is search for a certain value.
Usually something that represents a value that you are aware of - for example, number of bullets of your character.
Usually a big list of location in memory is found at first.
But then, you shoot a bullet, and now the list that you previously found (and only it!) is searched for the new value.
Each step discards the "false positive" finds, until in the end you know the location of the variable that you searched for.
After doing this you are able to change it as well.
Now, going to the general topic - this technique is only a specific approach, and while very helpful in some cases, many times you need stronger and different tools.
Here's a very similar question: How can I find the data structure that represents mine layout of Minesweeper in memory?
I personally find IDA to be an amazing tool for reverse engineering and analyzing an application (both statically and dynamically).
In combination with "idapython" (ida binding for python) it feels unstoppable :)
Reverse engineering requires that you have at least basic knowledge of your target machine architecture - for example, x86 instructions.
Search for IDA tutorials to get the hang of it.
There are many "crackme's" floating around, those are challenges to crack (for educational purposes) varying types of application protections.
It will teach you a lot.
You can also search google for "reverse engineering for beginners".
The web has tons of resources on this topic. The amount of information can be intimidating at first, so make sure you find a basic site that helps you to build your skills gradually.
Another important term that you should know is "hooking". While making it yourself will teach you the most, there are libraries that perform this operation for you.
The idea is to gain control over a certain function.
Whenever anyone calls that function, the control is first passed to your code, and you can decide what to do.
For example, you can decide to simply log this call to a file and call the original function,
or you can do more complicated things.
I found http://tuts4you.com/ to contain many useful tutorials and snippets of information.
Oh, and as people said, Java is not your friend in this case.
C/C++/Assembly probably are.
Starting a completely new topic, especially reverse engineering is tricky in the beginning, but I can assure you it's very rewarding.
Edit:
I have a surprise for you:
http://www.uninformed.org/?v=1&a=7
I simply googled reverse engineering tutorial mine sweeper ;)
Good luck :)

Based on your development stack, which is easier for you and why? Debugging or logging?

Please state if you are developing on the front end, back end, or if you are developing a mobile/desktop application.
List your development stack
Language, IDE, etc..
Unit Testing or no Unit Testing
Be sure to include any AOP frameworks if used.
Tell me if it is easier for you to use a debugger or to using logging during development, and why you feel it is easier.
I'm just trying to get a feel for why people choose to use a debugger or logging based on their development stack.
[Front end and Back end. Desktop]
As usual: it depends....
Debugging is better if you are investigating behaviour at a distinct place in the code and/or you don't know what objects you will need to inspect and you don't mind interfering with the natural speed/order of code flow
Logging is better if there is a known variable or variables you need to monitor often over a wide swath of the flow AND when you want the code to run naturally without interruptions. Logging is also a useful addition to unit testing.
It entirely depends on the type of problem. A lot of the work that I do currently is done on the back-end (C#, WCF-services). I typically find it easiest to use logging to get a rough idea on where and when a problem occurs, then I try to tailor a test that provokes the behaviour, and then use debugging in order to fix it.
I mainly use logging and unit testing, though I think my greatest weakness as a programmer is that I am not proficient in using gdp. I can do the basic stuff (breakpoints, watches) but don't really know enough to really tap into the power it really has.
I feel some discord in the question. Debugging—according to Wikipedia—is:
Debugging is a methodical process of
finding and reducing the number of
bugs, or defects, in a computer
program
Logging is an automatic writing of trace text records while program is running.
So I use logging as a part of debugging. And I think many people are. Otherwise, what are logs were made for? Well, maybe for further numeric analysis, but that's another story.

How can I use ToUnicode without breaking dead key support?

A similar question has already been asked, so I'm not going to waste time re-explaining it, an existing discussion can be found here:
ToAscii/ToUnicode in a keyboard hook destroys dead keys
The reason I'm posting a new question however is that I seem to have come across a 'solution', but I'm not quite sure how to implement it.
This blog post seems to propose a solution to the problem of ToUnicode killing dead-key support:
http://www.siao2.com/2005/01/19/355870.aspx
However I'm not sure how to implement the suggested solution. A push in the right direction would be greatly appreciated.
To be clear, the part I'm referring to is this:
There are two ways to work around this:
1) You can keep calling ToUnicode with the same info until it is cleared out and then call it one more time to put the state back where it was if you had never typed anything, or
2) You can load all of the keyboard info ahead of time and then when they type information you can look up in your own info cache what the keystrokes mean, without having to call APIs later.
I'm not quite sure how to do either of those things (keyboards and internationalization are far from my strong point), so any help would be greatly appreciated.
Thanks
The first part of the answer is entirely information-free. However, the second part does make sense. ToUnicode() should have been a pure function, which merely acts as a lookup. However, it isn't. But you can call it repeatedly for all expected inputs, store those in your own lookup table and access that.
I'd recommend that Microsoft adds a lookDontTouch flag to the wFlags parameter; that would be a trivial non-breaking API fix.
If you broaden your search to include key logging, you might get some answers. The method presented in the link is extremely cumbersome compared to ToUnicode, but it works. It evolves around finding the current active keyboard layout from the registry and then manually load and parse the proper DLL.
As a note of warning, I've seen the loading part fail miserably on 64-bit Windows.