Sometimes it doesn't bring up a debugger no matter how hard and fast you press cmd+. -- what can be done in this case ?
Then you're out of luck really. There's one slight chance (which I have never tried) that you could use OSProcess to intercept SIGUSR1 and then kill / suspend some processes. That's pretty dangerous though.
My advice: frequently save your image and commit your work often. Then you don't really have to care too much; simply kill the VM and restart.
Out of curiosity: which version of Pharo are you using?
Related
my understanding about debugging process and debuggers is that when a breakpoint gets hit, all other threads gets frozen. However one of my colleague said that this option is configurable meaning that somewhere in Visual Studio options you can configure that other threads (where there is no breakpoint) continue to work as normal although the thread with breakpoint get frozen. I couldn't find any such settings in visual studio plus my colleague does not remember where he saw that setting although he seem pretty confident that this option exists.
Can someone confirm if its even possible to have other threads running while one thread gets frozen due to breakpoint? Also if there is such a setting, please let me know where to find it.
The debugger always freezes all threads when a breakpoint hits. You have however do have control over what happens to threads when you press F5 to continue execution. You can use the Freeze toolbar button available in the Debug + Windows + Threads debugger window to prevent a thread from continuing when you press F5. Use the Thaw button to re-enable it.
I'm not familiar with VS, but I know gdb support non-stop mode since version 7.10, so I think it is possible to do like this with VS.
Here is the summary: "For some multi-threaded targets, GDB supports an optional mode of operation in which you can examine stopped program threads in the debugger while other threads continue to execute freely. This minimizes intrusion when debugging live systems, such as programs where some threads have real-time constraints or must continue to respond to external events. This is referred to as non-stop mode."
You can search 'non-stop gdb' for more details.
I don't know if this is possible but frankly if it is, it shouldn't be. Yes it is theoretically possible to break one thread while the others keep running, but keep in mind that with this there is the potential that one of the running threads will try to interact with the frozen thread. this causes all kinds of problems with your current frozen thread. I suspect the debugger was designed with this in mind, so there isn't a setting that allows this. If someone else knows differently please let me know because i find myself curious as well
How can I get stacktraces across all threads of an already running process, on Linux x64, in a way that is the least invasive and impacting as possible?
Things I've thought of till now:
gdb - I'm afraid it would slow the process too much, and for too long;
strace+ - no idea what performance it has, any experience anybody? still, IIUC, it traces only syscalls, and I can't even expect each thread enters a syscall, specifically some threads may be already hanging;
force crash & get a coredump - yeah... if I could do that easily, I would probably already be busy debugging... please, let's assume there's no elephant in the room, for the purpose of this question, ok?... pretty please...
There's a gcore utility that comes with gdb. You don't need to force a crash to get a core dump.
That's exactly what pstack does. See http://www.linuxcommand.org/man_pages/pstack1.html
I'm working on linux and I'm using a pthread_rwlock, which is stored in shared memory and shared over multiple processes. This mostly works fine, but when I kill a process (SIGKILL) while it is holding a lock, it appears that the lock is still held (regardless of whether it's a read- or write-lock).
Is there any way to recognize such a state, and possibly even repair it?
The real answer is to find a decent way to stop a process. Killing it with SIGKILL is not a decent way to do it.
This feature is specified for mutexes, called robustness (PTHREAD_MUTEX_ROBUST) but not for rwlocks. The standard doesn't provide it and kernel.org doesn't even have a page on rwlocks. So, like I said:
Find another way to stop the process (perhaps another signal that can be handled ?)
Release the lock when you exit
#cnicutar - that "real answer" is pretty dubious. It's the kernel's job to handle cross process responsibilities of freeing of resources and making sure things are marked consistent - userspace can't effectively do the job when stuff goes wrong.
Granted if everybody plays nice the robust features will not be needed but for a robust system you want to make sure the system doesn't go down from some buggy client process.
i wrote a program that needs to continuously run. but since im a bad programmer it crashes every so often. is there a way to have another program watch it and restart it when it crashes?
Not to be specious, but if you're a bad programmer, what's to say your watching programming won't fail too ;) And, you should get better so that you don't have this issue (for this reason). That said, you will probably have need of the following answer eventually.
However, if getting better isn't possible, just run a cron job at regular intervals looking for the name of your program in the output from 'ps'. And that answer you can get from superuser.com
No need for 3rd party programs
All of this can be accomplished with the linux inittab
inittab MAN pages
Look for "respawn"
You can use supervisord
http://supervisord.org/
Since Stackoverflow is a programming site, let me give you an overview of how such a watcher would be implemented.
First thing to know is that your watcher will have to start the watched program yourself. You do this with fork and exec.
What you can then do is wait for the program to exit. You can use of the wait system calls (i.e. wait, waitpid or wait4) depending on your specific needs. You can also catch SIGCHLD so that you can get asynchronously informed when your child exits (you will then need to call wait to get it's status).
Now that you have the status, you can tell if the process died due to a signal with the macro WIFSIGNALED. If that macro returns true, then your program crashed and needs to be restarted.
It still won't continuously run if you have another task monitoring it... it will still have a short amount of down time while it restarts.
Additionally, if you are acting as a network (or local) server process, you'll lose any state about requests in progress; I hope this is ok (Of course your clients may have built-in timeout and retry).
Finally, if your process crashed while it was in the middle of storing any persistent data, I hope it has a mechanism of coping with half-written files, etc.
However, if you intend it to be robust, all of these things should be true anyway, so you can use something like supervisord safely.
I use Monit to watch over my programs and services.
We have a monitoring application built on swt and running on linux. we have few buttons and a dynamic part that changes as we click on these buttons. The problem is that if some ones click too rapidly the cpu could reach 100% and hanging forever. We observed this rapid cpu spikes only on Ubuntu Linux where as windows it runs without on itch. We are sure that our app does repainting whenever we click (we have dynamic part) the button and that's by design. The problem is not alone with the dynamic part. One solution is to ignore rapid clicks.
We are wondering if we can ignore rapid Button clicks to avoid cpu spiking all the way to 100%. If that doesn't work we may have to redesign the dynamic part which we prefer as last option. suggestions/comments are greatly appreciated.
Another solution is to increase your memory with -Xms512m -Xmx512m
It sounds like the application is simply deadlocking. Are you using threads?
Check to see if the repaint is indeed the root cause of the application hanging. Also check to determine which thread it is in using:
Thread.currentThread()
If it is the main thread, then something is inherently wrong; it could be a problem in Java itself. If it is a thread, make sure that it isn't waiting for another thread to finish synchronizing.
I have the same problem in Ubuntu. But on OpenSuse, it seems a lot better.
Things you can try:
Set the anti alias and advanced option of the GC, like:
gc.setAntialias(SWT.OFF);
gc.setTextAntialias(SWT.OFF);
gc.setAdvanced(false);
And check if you are using the commercial graphic driver (i.e. from NVIDIA or ATI) and not the open source driver.
Try this or use pstack or lsstack. When the app runs a long time (or hangs) is when it's begging you to just take a look and see what it's doing.
Many people have experienced performance problems (i.e. very high CPU consumption) with SWT applications on Gtk+ when updating widgets too often. The actual cause seems to be Gtk+.
Although a bit outdated, here's a throughout explanation of such performance problems.
You could try replacing your SWT components with embedded Swing ones and check whether the problems is still reproducible.