An unidentified process on macOS periodically creates an empty temporary file in my Downloads folder but doesn't remove it later
I managed to figure out that immediate culprit is mktemp, but I want to understand which process calls it
I figure that I can use $ lldb > process attach -name mktemp -watifor to attach to mktemp when it's being launched, but can't figure out how to know who called it in first place
Is there any solution whether with or without lldb to know it?
That's actually a little trickier than you might think.
You can find the parent process of a given process on macOS easily by running ps -j <PID> though Terminal. The parent pid is the third column in the output. Or Activity Monitor has a hierarchical display that shows these relationships graphically.
lldb prints the pid of the process it is attaching to when it attaches, or you can find it in the output of the lldb command target list. So that's easy to find...
However, for technical reasons, when the debugger attaches to a process that process gets "reparented" by the kernel to the debugger. So if you ask a process running under lldb who its parent process is, the answer will always be "debugserver" - which is lldb's debugger stub. And there isn't an easy way to see what the original parent was.
I got this to work, though this is a bit of a hack. You want to suspend the process you are debugging so it doesn't exit on you, then detach from it so it gets reparented back to the real parent. So:
In lldb, run:
(lldb) expr (void) task_suspend((void *)mach_task_self())
Since that suspended the task before returning, the command won't actually complete. So
Use ^C in the lldb console to interrupt the expression evaluation. The target process is already suspended so this will just cancel the task_suspend return code.
Now detach:
(lldb) detach
When you do that the mktemp process will be reparented by the system back to its original parent,
Now you can run ps -j in Terminal and find the process you are looking for, and it will be the original parent.
If you need to get the process running again, attach to it with lldb again and call task_resume with the same arguments as you called task_suspend above.
Related
You can force garbage collection in java using jcmd <pid> GC.run as shown at this StackOverflow link: How do you Force Garbage Collection from the Shell? . I understand that forcing garbage collection is frowned upon, but I was wondering if there was a similar command for golang. Like this question, I would like know if garbage collection can be done from the command line instead of calling Runtime.GC().
It is not possible to run the GC from the command line. Think that your program is a standalone compiled version.
If you need to "force" the GC to run at certain times, I think you could use two formulas:
In your app, check the existence of a file with inotify. When the file appears, you run the GC
In your app, wait for a signal from the operating system (Linux), such as SIGUSR1, and run the GC. Then you send the signal from the console using:
kill -10 pid
Where pid is the identifier of the running program as it appears in ps -aux
Gameconqueror can update the variables it found continuously without stopping the program it's tracing. But as I know you have to use ptrace() to gain access of the specified program and when you do that it automatically stops the debuggee. But somehow Gameconqueror manages to do it's job without interrupting the debuggee(and it updates itself like every half second).
I think if Gameconqueror can do it, also gdb should be able to do it. I tried to enter some commands after continuing the debuggee, gdb doesn't give any error but also doesn't display anything. I'm very confused.
You need to make use of asynchronous mode within gdb. This is documented here:
https://sourceware.org/gdb/onlinedocs/gdb/Background-Execution.html#Background-Execution
For example:
(gdb) continue &
Will continue your program and then immediately return to the command prompt, allowing you to issue further commands while your program is still running.
If you want to stop your program you need to use the interrupt command, as the usual Ctrl+c will not work.
I have an application made with matlab compiler.
I want to do some shutdown activities whenever it ends. As it seems to be impossible to catch signals in matlab (or I'm not able to), I checked to use onCleanup (Matlab: Is it possible to create signal handlers (.m scripts)). It is working within matlab (native), but not within the compiled application.
I tried to end the application with CTRL-C and with taskkill (which only work with /f). In both cases the onCleanup-method was NOT executed.
For testing purposes here
function sigtest(varargin)
remainder=onCleanup(#()save('exit.mat'));
b=1;
while true
disp(datestr(now));
a=rand(round(5*b));%to be saved
pause(10);
b=a(1);
end
my source code, which I compiled via mcc -m -v sigtest.m.
As onether try, I inserted the lines
myexiter=addlistener(System.AppDomain.CurrentDomain,'ProcessExit',...
#(a,b)save('listexit.mat'));
after line 2, but also this .NET-Event is not working.
If you're registering shutdown activities within M-code, they're only going to work on a graceful shutdown of the process. The taskkill /f command will do a "forceful" shutdown, which I think will terminate the process immediately. The Matlab interpreter won't get a chance to run whatever cleanup code is still pending. I think Ctrl-C on a console application (which the compiled sigtest.m will be running as) will have the same effect. Same applies to the .NET-Event: if you forcefully kill the process, that callback never gets a chance to run.
If you want on-exit code, or any other cleanup stuff, to run, you need to find a way for the program to find out when it should exit and initiate a more graceful shutdown itself. For example, in your sigtest example, you could check stdin at the end of every pass through the loop, see if the user has typed 'quit', and if so call exit(). Then your onCleanup stuff should run.
In a GUI compiled Matlab application, this is more straightforward; you have GUI controls to exit the application. I don't know what the canonical way is to make a console compiled Matlab application responsive to user exit requests, or if there even is a good one. You might want to make this a GUI app if you think the user might want to request a graceful abort of its operation.
I have a Perl program on Windows that needs to execute cleanup actions on exit. I wrote a signal handler using sigtrap, but it doesn't always work. I can intercept Ctrl-C, but if the machine is rebooted or the program is killed some other way, neither the signal handler nor the END block are run. I've read that Windows doesn't really have signals, and signal handling on windows is sort of a hack in Perl. My question is, how can I handle abnormal termination the Windows way? I want to run my cleanup code regardless of how or why the program terminates (excluding events that can't be caught). I've read that Windows uses events instead of signals, but I can't find information on how to deal with Windows events in Perl.
Unfortunately, I don't have the authority to install modules from CPAN, so I'll have to use vanilla ActiveState Perl. And to make things even more interesting, most of the machines I'm using only have Perl 5.6.1.
Edit: I would appreciate any answers, even if they require CPAN modules or newer versions of Perl. I want to learn about Windows event handling in Perl, and any information would be welcome.
In all operating systems, you can always abruptly terminate any program. Think of kill -9 command in Unix/Linux. You do that on any program, and it stops instantly. No way to trap it. No way for the program to request a few more operating system cycles for a clean up.
I'm not up on the difference between Unix and Windows signals, but you can imagine why each OS must allow what we call in Unix SIGKILL - a sure and immediate way to kill any program.
Imagine you have a buggy program that intercepts a request to terminate (a SIGTERM in Unix), and it enters a cleanup phase. Instead of cleaning up, the program instead gets stuck in a loop that requests more and more memory. If you couldn't pull the SIGKILL emergency cord, you'd be stuck.
The ultimate SIGKILL, of course is the plug in the wall. Pull it, and the program (along with everything else) comes to a screeching halt. There's no way your program can say "Hmm... the power is out and the machines has stopped running... Better start up the old cleanup routine!"
So, there's no way you can trap every program termination signal, and, your program will have to account for that. What you can do is see if your program needs to do a cleanup before running. On Windows, you can put an entry in the registry when your program starts up, and remove it when it shuts down and does a cleanup. In Unix, you can put a file or directory name starting wit a period in the $ENV{HOME} directory.
Back in the 1980s, I wrote accounting software for a very proprietary OS. When the user pressed the ESCAPE button, we were suppose return immediately to the main menu. If the user was entering an order, and took stuff out of inventory, the transaction would be incomplete, and inventory would be showing the items as being sold even though the order was incomplete. The solution was to check for these incomplete orders the next time someone entered an order, and back out the changes in inventory before entering the new order. Your program may have to do something similar.
Maybe a simple question.
When I attach to a process, I run "continue" to make it continue to run.
Then I want to some other job like "add-symbol-file" with need not interactive with target process, but after the "continue" command, the gdb console will block, so I can not do any action before I break the process.
Is there any way that I can do such thing without suspend the process?
Make sure the console which gdb is running in has keyboard focus, then press CTRL-C. This will usually result in a SIGINT signal to be sent to gdb.
With me, GDB then pauses execution of the program and accepts user commands again.
Should the CTRL-C not work (perhaps different config) try to send the signal manually:
Find out the pid of gdb such as with command top and then send a SIGINT to gdb:
kill -2 pidhere
Until recently you couldn't do what you want, but the newly released
version 7.0 of gdb has what is called a "non-stop" mode, in which the
gdb prompt / console can be used while the program is running.
See http://sourceware.org/gdb/current/onlinedocs/gdb_6.html#SEC47
You may want to study the remote gdb mechanisms a bit for something like that.
For understanding the debugging process more read this short article.