I have a Perl programs that will takes a long time to run. The user may exit it occasionally and I hope to implement a mechanism to recover the program from where it exited.
I have an idea to use Storable/Dumper module to save the state of the program before it exited and restore the state after it resumed.
But how can I move the program to where it exited? Can I just set a recover point from where it exited and move to the recover point directly after it resumed?
You can use the concept of transactions and design the program around that, but having the user kill a process as an expected way of interacting with it doesn't sound like a good idea.
Maybe giving better feedback to the user about the program state would solve this issue instead of dealing with hacky behaviour.
Related
I have been trying to fuzz using both AFL and Libfuzzer. One of the distinct differences that I have come across is that when the AFL is executed, it runs continuously unless it is manually stopped by the developer.
On the other hand, Libfuzzer stops the fuzzing process when a bug is identified.I know that it allow the addition of parallel fuzzing through the jobs=N command, however those processes still stop when a bug is identified.
Is there any reason behind this behavior?
Also, is there any command that allows the Libfuzzer to run continuously unless the developer stops the fuzzing process?
This question is old but I also was in need to run libFuzzer without stopping.
It can be accomplished with the flags -fork=<N of jobs> combined with -ignore_crashes=1.
Be aware that now Ctrl+C doesn't work anymore. It is considered as a crash and just spawns a new job. But I think this is a bug, see here.
I have built a command line app that will listen for an argument and kick off a never-ending process. What I can't seem to figure out is how to keep that process running until I send a different argument back to the command line app to end it. I am able to accomplish this easily in the main thread, but I want to be able to gain access to the command prompt to issue an end command to stop that process.
My first thought was to go to threading, but I can't seem to get that to work. What is the solution you would use in this case?
I'm trying to debug a multithreaded app in Eclipse. There are 3 Threads
Read
Write
Controller
Read and Write both access a method in Controller. I am trying to debug a problem when Write executes that Controller method.
I've got a breakpoint set in the Write thread and the Controller. I break in Write and I turn off my network connection to simulate my error and hit resume so I wind up at my breakpoint in Controller.
When I'm there Controller works as it should: it kills the Read and Write threads (I think) and starts new Read and Write threads. After killing Read and Write, I turn on my network connection to simulate the problem being solved.
All this is great. What should happen now is everything continues on its merry way. Except what really happens is the Read thread executes and I wind up hitting the breakpoint I set in Controller again - the same one I previously hit from Write. To make matters worse, it still thinks the network connex is unavailable - which makes no sense as I've re-enabled it.
This all makes me wonder if I need to stop the Read thread from executing somehow. Do I need to suspend it via Eclipse? Is it even possible to kill a thread from an app running in the debugger?
Mark
Do I need to suspend it via Eclipse?
No there is no need to suspend a thread in order that you code works. I suspend rarely I thread, I do it when I suspect that is waiting for something I don't except. I use breakpoints to control the stop and sometimes with properties. Here is an interresting answer.
Is it even possible to kill a thread from an app running in the debugger?
No and if it was possible, it will not be a good idea regarding the current specifications of Java. A good method to stop a thread is to use a flag to exit from the run() method properly : see here
Are you sure that you exit from you Read and Write threads ? One way is to add debug info in you run method :
run()
{
System.out.println("start : " + this.getName());
// do your process
System.out.println("stop : " + this.getName());
}
Logging is sometimes easier than debugging in multithreading. It is difficult to be more specific without the code.
I'm trying to port a C console program over to iPhone. I have imported all the code into my project, and I'm calling it's main() in an NSOperation when the user clicks a button on the UI.
Anyway, this program is complicated and creates many of its own threads. The program calls "exit()" many times as well- this would crash the entire iPhone app, but I really want the user to be able to restart the C program if it does it.
I've been working on cleaning up these exit conditions, and I've used pthread_exit() in some of the child threads the C program creates. However, when I call pthread_exit() in the thread that is created from the NSOperation object, the app's main thread get's a SIGABRT signal and the entire app crashes.
Am I correctly assessing the situation? I am new to iOS programming so this signal may be coming from elsewhere... And if I am correct, what is the best way to get around this?
(Oh, and about using "return 0" to exit this NSOperation thread: the condition I want to exit from is nested deep in C program functions, I want to avoid changing as much structure of the program as possible, since it already very complicated)
Thanks in advance for any help!
NSOperationQueue executes it’s operations on GCD queues. While those execute their jobs on pthreads those threads are private to GCD and you are not allowed to modify or exit them using pthread APIs. There is documentation on Compatibility with POSIX Threads, which explicitly states which pthread functions are allowed and which not.
To solve your problem you probably should not let your pthread code run on a NSOperationQueue but on a new POSIX thread you create just for that.
don't kill your pthreads -- let them exit naturally. as well, exit != pthread_exit. the author was clearly not considering cleanup when calling exit. so you are really just swallowing fatal errors by killing the threads.
it would be a miracle if it were incapable of resulting in undefined behaviour, or other nasty things like leaks or deadlocks.
in short, the library is being misused. you should handle the errors gracefully if you intend to continue execution. that can require a lot of work.
I have a computationally intensive scala application that hangs. By hangs I means it is sitting in the process stack using 1% CPU but does not respond to kill -QUIT nor can it be attached via jdb attach.
Runs 2-12 hours at 800-900% CPU before it gets stuck
The application is using ~10 scala.actors.
Until now I have had great success with kill -QUIT but I am bit stumped as to how to proceed.
The actors write a fair amount to stdout using println which is redirected to a text file but has not been helpful so far diagnostically.
I am just hoping there is some obvious technique when kill -QUIT fails that I am ignorant of.
Or just confirmation that having multiple actors println asynchronously is a real bad idea (though I've been doing it for a long time only recently with these results)
Details
scala 2.8.1 & 2.8.0
mac osx 10.6.5
java version "1.6.0_22"
Thanks
if you just wanna remove the process from the run queue, the obvious choice is
kill -9
Of course you wanna avoid having to do that in the first place, but you do not provide any information that would allow us to help you with that. Writing to stdout in multiple actors is indeed a bad idea, but the worst thing that could come from that is garbled output.
Most times I have seen the JVM react like that is when it goes into no permgen space. It will then be incapable of anything (even dying). You don't find any traces of that in your printout? Have you tried to increase the permgen space?