I was going through Linux Programmer's Manual about Alternative Signal Stack.
http://www.kernel.org/doc/man-pages/online/pages/man2/sigaltstack.2.html
I see that sigaltstack() is used when user's stack is corrupted or when it overflows. My problem is how to detect at run time if the stack is corrupt ?
In my running program in production, I want to go for alternate signal stack, if my program detects, stack got corrupted. Is it the right question to ask ? People in some threads talk about using debugging tools like Valgrind ( and possibly others) but unfortunately the luxury is not available in production.
You can't really detect a corrupt stack from the process itself - once your stack is corrupt, your whole program (including whatever functions/variables you could try to use to detect corruption) is unpredictable.
And you can't really repair a corrupted stack even if you could detect it. There is no telling what damage was cause by running code on a corrupt stack. So the best (probably only) thing to do is just quit at that point anyway.
Read the man page completely, the reason it gives for using the alternate stack is a good one (handling SIGSEGV). Although you can't generally repair that either, so quitting is pretty much the only thing you can do then.
Related
I am new to Xcode and the profiling tool, instruments. I tried to find leaks of my c program. Everything is fine. It shows no leaks, but I don’t understand some terms used in the program. Does mean I still have memory leaks somewhere else in the program?
Applications like the debugger and Instruments may hook into your program after the OS has already started it running. What the message is saying is that it doesn't know how a given piece of memory was allocated because it was allocated before Instruments hooked into your program. So it has no way to track where it came from. It may or may not mean that there are more actual leaks in your program.
I believe that you can start your program from Instruments in most cases, which I think would eliminate the issue. Once you've run it once, you should be able to press the Record button (the red circle) again and it should run the app once more. I think in that situation, it should have access to all of the allocations your app makes.
For what it's worth, I have seen this message before and had it go away during the same run. It was as if it suddenly found the data that explained where the leak came from. I've also seen it happen on one run and be gone on a subsequent run with the same data. In that case it seemed like a timing issue of Instruments and not a legitimate leak.
My delphi program (NOT for .NET) on windows 7 seems to be running for couple of days straight and then the program sort of freezes with all of its windows painted with blueish grey color as if its windows are disabled. You simply don't have control over the program anymore but has to kill its process and start it up again. You don't need to reboot the system itself.
Has anyone experience this or anything similar? If so, what did you do to resolve or try to resolve it?
Thanks,
Your question context is very vague. We do not have any information about your application, even its design and architecture.
Nethertheless, my (general-purpose) suggestions are the following:
If your application is not multi-threaded, do the process in background threads, then leave the main thread ready to process GDI messages;
If your application is multi-threaded, take care that all VCL access from background threads are made via a Synchronize call;
If your application is multi-threaded or use timers, take care that no method is re-entrant (in some circonstances, you may come into a race condition);
Hunt any memory leak;
Use a detailed logging of the program execution, logging all exceptions risen, to guess the context of the program hang (it may be used on the customer side also to hunt race conditions);
Download the great free tool named ProcessExplorer (now hosted by Microsoft), and check out the state of your frozen program: you will see detailed information about threads, CPU use, memory, network, libraries, handles - this is a must have for any serious debugging - track especially the GDI handles leaks (number of those should remain stable);
If you did not check it already, take a look at the global Windows system event log: there may be some information here;
Perhaps a third party component or library is responsible of the process hang: try to isolate the part of your code which may be responsible of this hang.
I've Delphi application running for months without any problem. Issue is definitively in application code, not in the Delphi architecture (its RTL and VCL are very stable).
The bluish grey color is probably the default window color, meaning the window is no longer painting itself. This is consistent with the other symptom that the program no longer responds to any input. This means it isn't processing any window messages.
The easiest way to debug is to run the program in a debugger, and when it's hung just stop it and see where it's at.
If you have a memory leak you may eventually run out of memory in your process space, and it's possible that the program doesn't properly respond to that condition. Check Task Manager to see the amount of memory it's using.
Yes I fixed several hangs and other problems in the past years.
I used ProcessExplorer before (to view the stack), but it needs Microsoft debug symbols. And with Delphi you can only create a .map file. With map2dbg I could convert the .map to a .dbg, but this does not always work (note: .dbg is deprecated, newer versions of Microsoft debugging tools do not use them anymore).
So I made my own tool :-)
It is part of "AsmProfiler Sampling" tool:
http://code.google.com/p/asmprofiler/downloads/detailname=AsmProfiler_Sampling%20v1.0.7.13.zip
Click on the "Stack view of Process" button in the first screen.
Then select your process from the list and double click on it:
http://code.google.com/p/asmprofiler/wiki/ProcessStackViewer
Now you can view the stack trace of each thread. If the GUI does not respond, the main thread hangs, so check the first thread. (note: sometimes you see an "emtpy" stack because a function misaligned the stack for calculation etc, use the raw strack tracing algoritm to get more the full stack again (with a lot of false positives, because every pointer on the stack which is possible a function is shown!)).
Please post the stack here if you can't solve it, so we can take a look at it.
Note: it uses the jclDebug.pas unit of the JEDI library, so it can read .map and .jdbg files (also .dbg and .pdb debug files of Windows dlls) and also internal JCLDEBUG sections (embedded .jdbg file in one .exe). So you must at least build an .exe with detailed (!) map file, see Project Options -> Compiler -> Linking.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
If possible, describe platforms/languages/symbolic formats supported and if full support is provided (historical states back) or partially (only code can rerun with no rescue for states).
Further information about performance or resources needed is welcome but optional.
The new IntelliTrace historical debugger feature in Visual Studio 2010 seems to fit what you're asking for. See Debugging With IntelliTrace:
Debugging with IntelliTrace, available
in Microsoft Visual Studio 2010
Ultimate, provides an enhanced picture
of your application compared with
traditional debuggers. Traditional
debuggers show you the state of your
application at the current time with
limited information about events that
occurred in the past. You must either
infer events that occurred in the
past, based on the state of your
application at the current time, or
restart the application to re-create
past events. With IntelliTrace, you
can actually see events that occurred
in the past and the context in which
they occurred. This reduces the number
of restarts that are required to debug
your application and the possibility
that an error will fail to reproduce
when you rerun the application.
GDB does, with reverse execution and checkpoint/restart.
Green Hills Time machine Debugger
Chronon for java supports full stepping back and seeing entire state info at any point in time.
PythonTutor (http://pythontutor.com/) Lets you do this for small code examples in several programming languages.
Dr. Scheme, also known as PLT Scheme, will let you step backwards and forwards in a Scheme program. Full support for maintaining the state, as far as I can tell, though I haven't used it much. Runs on Windows, Mac and Linux.
I have never used a debugger with the ability to step backward. I just did a Google search and didn't find much...
I did find this:
http://video.google.com/videoplay?docid=3897010229726822034
Searching for "Bill Lewis debugger" led me to:
http://undo-software.com/undodb_about.html
The ability to step backward implies preserving a lot of state: if you change a variable in one line of code, and then you want to step backward, presumably the variable should revert to its previous value. If you change a register, it should revert to its previous value, and that includes the flags register. If you allocated memory, presumably it should be de-allocated. And so on. It's a big job in general. It looks like this debugger is using copy-on-write technology to actually do all this. I guess if a virtual machine like VirtualBox is possible, so is this.
This is still not a mainstream feature. One feature I have commonly seen is the ability to "set the next line". Say you call a function and it returns a value that surprises you; you set the "next line" to the line before the function, and then single-step into the function. Microsoft Visual Studio debugger can do this and so can gdb (the jump command). This ability is of limited use if the function corrupted the stack. Then, you really need to start over!
Computers have gotten so fast, it's much less painful to start over from the beginning than it used to be. You can just set a breakpoint before the point where you want to go back, and re-run the program from the beginning.
I have a application which randomly freezes, including the IDE and it's driving me mad. That makes me wonder:
What's a good general strategy for finding the cause of random freezes?
If you are wanting to check from outside of a running app then I would potentially use the sysinternals.com toolset from Mark Russonivich, the perfmon tool allows you to trace file / registry access and check the trace for delays - and what is being accessed at that time. It will show the DLL call stack at that time with the right symbols can is useful for debugging problems external to an application that are causing delays. (I've used it to find out that an I/O filter associated to a security suite was the reason an application was piccking up a number of 1.5sec delays.)
If you're lucky, you can run your code in a debugger until it freezes, then stop the debugger to find the offending line of code. But if it were that easy, you probably wouldn't be asking for advice. :-)
Two strategies that can be used together are to "divide and conquer" and "leave bread crumbs."
Divide and conquer: Comment out increasingly larger portions of your code. If it still freezes, you've reduced the amount of code that might be responsible for causing the freeze. Caveat: eventually you'll comment out some code and the program will not freeze. This doesn't mean that last bit of code is necessarily responsible for the freeze; it's just somehow involved. Put it back and comment out something else.
Leave bread crumbs: Make your program tell you where it is and what it's doing as it executes. Display a message, add to a log file, make a sound, or send a packet over the network. Is the execution path as you expected? What was the last thing it was doing before it froze? Again, be aware that the last message may have come from a different thread than the one responsible for freezing the program, but as you get closer to the cause you'll adjust what and where the code logs.
You're probably doing things in the UI thread when you shouldn't be.
I would install the UserDump tool, and follow these instructions for generating a user dump of the application....
Once you have the user dump, you can use WinDbg, or cdb to inspect the threads, stacks, and locks, etc.
Often I find hangs are caused by locked mutexes or things like that.
The good general strategy is, run the program until it hangs. Then attach a debugger to it and see what's going on. In a GUI program, you're most interested in what the UI thread is doing.
You say the application hangs the IDE. This isn't supposed to happen, and I imagine it means the program is putting so much strain on the OS (perhaps CPU load or memory) that the whole system is struggling.
Try running it until it hangs, going back to the IDE, and clicking the Stop button. You may have to be really patient. If the IDE is really permanently stuck, then you'll have to give more details about your situation to get useful help.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 14 years ago.
Improve this question
This is not a newbie question:
My desktop computer that is running Windows Vista tends to freeze on occasions. Freezes last around 5-20 seconds after then, the systems goes back to normal like nothing happened. This happens fairly often (I can safely expect this to happen within 30 minutes). During the freeze, I can move the mouse cursor, however switching to the different application does not work. Key presses and mouse clicks are buffered, and are applied once the system unfreezes. I believe this is incompatibility with a driver, but would be interesting to know.
So my question is: How would one debug such scenario? Considering I can not isolate a process to take a memory dump of, or even if I could try to dump Explorer, I can't control the process that would create the memory dump.
** Clarification **
I guess since the question is misunderstood, I'll clarify; I am not concerned with fixing the system, I am interested in how to debug system code. How would you debug system resources? Is there any way to do something like adplus -crash on a system process to create a dump on an exception (if one does happen but is swallowed). Or is there a way start a debugger during bootup to make sure that it allows for monitoring of drivers as well. I am sure that this is done by driver developers on regular basis, so looking for some information.
Timur
This lack of responsiveness doesn't sound like a true freeze since you apparently don't have to reboot afterward. It might just happen because one or another applications has taken up 100% of cpu for a time, preventing all activity on the system. If you run Windows Task Manager or Process Explorer, you might be able to see that one or another apps has to 100% cup for a time. Process Explorer is nice because it shows more services as well as applications.
First place to start is with the system event log. See if it's disk non-responsiveness issue or if there is something else going on.
Take out everything that's not necessary (sound card, network card, connected printers, cameras, etc.).
Run for a while and if the problem doesn't occur, it was one of those devices, or a conflict between them.
If it still happens, go further; remove the mouse and keyboard and use remote desktop to control the computer, or try replacing your graphics card with another.
While it won't help Windows users, I'd like to mention the Linux Magic SysRq feature which can help at times like these.
A number of the Sysinternals utilities such as Process Explorer and Process Monitor might help to isolate what is causing the problem.
However, if you really want to debug the problem, look no further than Debugging Tools for Windows, and WinDbg in particular.