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 8 years ago.
Improve this question
Please take a look at my recent question here: Deadlock with no user code
How can you tell when the debugger is lying to you in this way? Other than, of course, showing that what it is telling you is impossible?
I don't like relying on that since I've seen so many 'impossible' states in a program that were in fact happening due to some subtle or esoteric problem.
Yes, those are pretty wacky stack traces, particularly the 1st one. Hard to theorize how that happened. It doesn't usually get that screwed up unless you debug optimized code.
Which is hint #1, never trust what the debugger tells you when you have to debug release built code. Strongly avoid it, you don't always have the luxury when you need to troubleshoot a deadlock however.
Strong hint #2 is paying attention to the code-flow. The normal one for a blocked thread, bottom to top in the Call Stack window, is yourcode => runtime (msvr120) => winapi layer (kernel32 et al) => native api (ntdll.dll). This is generally the case, there are a few cases where this flow is reversed, callbacks from the OS into your code, like window notification, thread-start (always at the far bottom of the stack for example), I/O completion.
Which is what's wacky, there is no realistic scenario where a low-level native api function like ZwWaitForSingleObject() could ever directly call into the C runtime library. That's bogus, only the top entry (Block) could be accurate. Yes, tough debugging that way.
Related
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 3 years ago.
Improve this question
I just started my college "adventures", and one of them is subject called operating systems. I must admit that the subject is the most boring ever. Last week, we got our first homework, and i do not know what to do as this is the first time ever i come up with Windows API functions or this topic in general. The task is very simple, we need to write very basic code in C that shows how does GetCurrentThread() work!!!???? I tried looking for solution online, but I could not find anything and our professor is not doing anything to help us. I found the use of functions like GetCurrentThreadID() but that is not what i need. Can somebody write simple program ( 20-30 lines of code ) which contains the use of this function (in C)?
Operating systems courses tend to suck because they take the simplest of concepts and try to make them convoluted.
Documentation for the GetCurrentThread () function is
https://learn.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-getcurrentthread
What it does not explain is that the return value for the function is a "handle." Windoze uses handles somewhat as pointers to objects but where you cannot access the object directly.
So you call GetCurrent() thread and it returns a "Handle to the Thread." That handle can then be used to do things with the thread.
Here are the things you can do:
https://learn.microsoft.com/en-us/windows/desktop/ProcThread/process-and-thread-functions
Some of these function pages have short examples.
So you could do:
print ("Thread ID: %d\n", GetThreadID (GetCurrentThread())) ;
and have the ID of the current thread.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am trying to take a look at the status of r7rs large but I cannot find any information
in scheme reports page, etc, just a talk from 2013. I searched around with google without success as well.
Is it still alive?
Where can I find information?
What would be the tentative date?
What is the progress at this point?
Thanks.
You can read about the R7RS process on the R7RS working group wiki. R7RS-large is listed under the "Working Group 2" section of the front page.
In particular, look through the StandardDocket and ConsentDocket sections. Standard docket is for stuff that's under discussion (and eventual voting). Consent docket is for generally-uncontroversial stuff that's likely to get into R7RS-large without having to be voted on.
There is no firm timeline that I am aware of (though I'm not part of the working group and do not speak for them). The standard docket is quite long, though, and they will have to process through most/all of it before you have anything that you can call R7RS-large.
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 8 years ago.
Improve this question
I have a little state machine in Java which has an unusual state.
The issue is ABORT ...
The task can have two final states: SUCCESSFUL, and FAILED.
But it would be nice to sometimes ABORT a task while it's in the queue, before it ever gets executed and during execution.
While ABORTED is a final state I don't want to have two (or even N) failed states.
FAILED and ABORTED will then have to be checked for. I could also see other failed states like TIMEOUT.
I guess I could have a generic CAUSE for the failure... which could be a TimeoutException, AbortedException, if I want to check for why it failed. Then I could just look at the cause.
Still not super happy with that either.
Any thoughts?
Understanding your problem only abstractly, here are my thoughts on this state machine.
I think FAILED needs to be a category comprising causes such as ABORTED, TIMEOUT, SEGFAULT, UNKNOWN etc. I don't like FAILED as it seems indicates there was some defect in the program or the environment, but I cannot think of a better antonym for SUCCESSFUL that doesn't convey the same meaning.
If the Java framework specifics are your concern, you could easily have an enum that represents these states without much trouble. You would only be checking for SUCCESSFUL or !SUCCESSFUL, as all non-successful things probably deserve similar handling at some level.
While you could take the Exception route, I do not find it sensible to have an AbortedException, especially if that is not actually an exceptional circumstance. Code that is expected should not trigger exceptions, when possible.
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 8 years ago.
Improve this question
I've been programming for about 5 months now. I started with C++ then C and finally Java. In this time I have never used the debugging feature on my compilers, nor do I know what it does. In class I have been taught nothing about the debugger so far (Altho class is barely starting in C, I learned C++ and Java on my own). What is debugging, what does it do and do you use it often? What are the uses for debugging? I've googled debugging, but I couldn't quite understand. Can anyone explain the debugging feature properly? From what I understand so far, it's a feature to help you find bugs, but I don't quite get how it works.
Debugging itself is the process of finding and exterminating bugs, nothing more and nothing less. So unless you're a perfect programmer who never makes any mistakes, you've done it.
A debugger, on the other hand, is a tool which assists in debugging. You can still debug without a debugger, but using a debugger gives you more options, and ways to go about it.
Without you mentioning specifically which debugger you're talking about (Visual Studio one, or gdb, or...) we can't really tell you how to use it, but, in a nutshell:
A debugger will let you execute the code one instruction at a time, or one line at a time. It will let you run your code until a place you're interested in, then stop. While the code is stopped, you can inspect the values of the variables to make sure things are in order, and in some cases even modify things on the run to test various scenarios.
Some of the techniques of debugging without using a debugger are:
print insertion, where you litter your code with printing commands that will allow you to track the state of your code while it is running,
code reading, where you read the code and try to find the places where your intention differs from what is actually written
mug conversations, where you try to explain your code to your friend (or a mug, or a penguin doll on your desk), and in the process see where your logic goes wrong
binary cut search, where you delete chunks of your code at a time and see if the error is still present
and many more.
Debugging allows you to examine the values of variables at each step of your code's execution. It is a good way to find stupid mistakes (among others). For example, you might not catch this off-by-one error:
for (int i = 0; i <= 10; i++)
{
MethodThatShouldExecuteTenTimes(i);
}
If you step through your code with the debugger, you'll see that the method is called 11 times.
If you write programs that always work first time, you will never need to find bugs.
If the program compiles, but doesn't work, how do you work out what's going wrong?
Adding lots of print statements works, but being able to step into functions, step through them and examine memory stores is really helpful.
One could say debugging is like violence - the last refuge of the incompentent!
But sometimes, we don't quite have the competence to avoid the bug, and a debugger makes life SOOOOOO much nicer.
Debugging is the process of finding the code that is not doing what you want it to do. It is a very necessary skill in order to be efficient in getting work done. It can consist of many things. Including but not limited to:
reading log files produced by the program
viewing messages transmitted by your program across the network
viewing the output of your program (e.g. does the web page display and act correctly)
viewing the stack trace of an exception
using the debugger to step through your code line by line so that you can see the values of variables at a specific point during execution.
The debugger can be used for more than just locating bugs in your program. It can aid you in understanding how existing code operates. You can set breakpoints in your code: a marker to tell the debugger to stop executing on that line. Then from that point you can begin stepping through your source code line by line.
In order to get a better feel for using the debugger, I recommend that you set a breakpoint in your code and step through it. You will then see exactly what I and others have said. What ever development environment you use should have instructions on how to use the included debugger.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
After fighting several versions of the CoreKeyGen created by some "minamoto" guy, a new version has appeared. This version is particularly sophisticated and seems to modify the actual binary itself, using a dylib known as libbassmod.dylib (this is in the keygen's Mac OS folder).
Has anyone ever come across this & can give me advice on how to stop it?
If so, how can I stop the keygen? it seems like the library can see what calls my app makes and stop them somehow, I'm not too sure.
I doubt that the "Minamoto" here is the real guy you are looking for, maybe just someone wanted to making fun of you. People in the scene won't have the time to read the post here, nor reply under their real nick.
Back to your questions, libbassmod.dylib is used for audio module playback. It's often used in windows key generaters by the Scene to play audio module formats such as XM, IT, S3M, MOD, MTM, UMX. more info you can read up here:
http://www.un4seen.com/
And about the idea of fighting them or making fun of them in your blog, IMO it will only bring you troubles(Espicially some groups like this one, CORE(which stands for "Challenge Of Reverse Engineering"), google for it if you want to know more about it).
Enough said, if I were you, I'd put my time on making my applications better instead of coding protections. That's the right and only way to get more customers(And believe me they hate software protections). Those who use cracks will never buy anything from you(Just see all those thinsg on MSJ), they use the cracked version of your application was just because they can use it for free, so actually you lose nothing.
libbassmod.dylib is for the background music playback...
What? A keygen usually means someone reverse engineered your key verification algorithm to produce their own algorithm that satisfies yours. There is nothing you can do to stop this, except use PKI or some variant of a whitelist of keys. Even then, they can just patch your program. If you want to know what the keygen is doing, you need to dissassemble it with a dissassembler such as Ollydbg, IDA Pro, etc, it should be fairly simple as keygens are tiny programs, although it's probably a waste of time.