I am trying to do something really basic;
Plot an array of integers as time-series data using JFreeChart. Previously the code was working perfectly fine. That is the point that drives me crazy.
However, now it fails to terminate after doing everything it is supposed to do. Active threads are as follows;
Thread[AWT-Shutdown,5,main]
Thread[AWT-EventQueue-0,6,main]
Thread[main,5,main]
I am using a Macbook with Mac OS 10.6.8 on it, and got a set of recent software updates.
Does anybody have any clue about where to start, and what to look for?
You can get more infomation from the terminal:
Launch your program in the background
$ java -jar dist/program.jar &
Get its process id
$ ps
PID TTY TIME CMD
714 ttys000 0:00.01 -bash
727 ttys000 0:01.52 /usr/bin/java -jar dist/program.jar
Obtain a thread dump
$ kill -QUIT 727
Look for anything not in State: WAITING or State: RUNNABLE
Your IDE's profiler may offer a more friendly view of the same information. See also JLS ยง12.8 Program Exit. An sscce may help, too.
Related
I am trying to learn Hugo using a Go debugger called dlv. And I am pretty stuck. After:
go get -v github.com/gohugoio/hugo
cd $GOPATH/src/github.com/gohugoio/hugo
go build -gcflags="-N -l"
dlv exec ./hugo -- -s /path/to/the/projectdir
This hangs. Pressing Ctrl+C runs hugo as normal. As far as I can see dlv debug not only produces the same behavior but it's the exact same: the produced binary called debug is the exact same as the hugo I built with go build -gcflags="-N -l".
dlv launches a number of child processes, these disappear after a while. The hugo process is visible via ps and pidof hugo but strace -ppidof hugo`` reports strace: attach: ptrace(PTRACE_ATTACH, ...): No such proce. Checking after, it's still in the ps list, the same pid. I would guess because it's in t state as it is being traced.
How could I then watch Hugo running?
Aaaaand it's Linux subsystem for Windows! I never thought that'd make a difference but following Jonah B's answer " I am on fedora" I tried it on a Debian box and it worked. I am surprised because strace works fine on WSL (actually the github instructions on filing a report includes strace). I filed this bug.
Hmm, doesn't happen for me. dlv prompt appears right away. I am on fedora, have been using hugo regularly over the past week or so.
$ dlv exec ./hugo -- --cleanDestinationDir -s /path/to/blog/root/
Type 'help' for list of commands.
(dlv) c
| EN
+------------------+----+
Pages | 25
Paginator pages | 0
Non-page files | 0
Static files | 11
Processed images | 0
Aliases | 0
Sitemaps | 1
Cleaned | 0
Total in 46 ms
Process 41032 has exited with status 0
$
Same experience here. However it doesn't hang, it just takes a significant time to reach the dlv prompt.
Check the usage of your memory (for instance with mpstat or vmstat if you are on Linux). I have 16G main mem and 16G of swap. Until the dlv prompt is reached, nearly all my memory and a significant amount of swap is consumed. During the startup time any playing video or music stutters and the PC is practically unusable until dlv is ready.
Hugo is pretty large app in that respect.
Is there a way to exit from gdb connnection without stopping / exiting running program ? I need that running program continues after gdb connection closed.
Is there a way to exit from gdb connnection without stopping / exiting running program ?
(gdb) help detach
Detach a process or file previously attached.
If a process, it is no longer traced, and it continues its execution. If
you were debugging a file, the file is closed and gdb no longer accesses it.
List of detach subcommands:
detach checkpoint -- Detach from a checkpoint (experimental)
detach inferiors -- Detach from inferior ID (or list of IDS)
Type "help detach" followed by detach subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
Since the accepted (only other) answer does not specifically address how to shut down gdb without stopping the program under test, I'm throwing my hat into the ring.
Option 1
Kill the server from the terminal in which it's running by holding Ctrl+c.
Option 2
Kill the gdb server and/or client from another terminal session.
$ ps -u username | grep gdb
667511 pts/6 00:00:00 gdbserver
667587 pts/7 00:00:00 gdbclient
$ kill 667587
$ kill 667511
These options are for a Linux environment. A similar approach (killing the process) would probably also work in Windows.
A legacy program most likely gets into an infinite loop on certain pathological inputs. I have >1000 such instances, however, I suspect that the vast majority of them trigger the same bug. Therefore, I would like to reduce the >1000 instances to the fundamentally different ones. The first step is to pause the application after, say, 10 seconds and collect the backtrace.
If I run:
gdb --batch --command=backtrace.txt --args ./legacy_program
with backtrace.txt
run
bt
and I hit Ctrl + C after 10 seconds in the same terminal I get exactly the backtrace I want.
Now, I would like to do that automatically. I have tried sending SIGINT (the expected equivalent of Ctrl + C) from another terminal but I do not get the backtrace anymore. Here are some of my failed attempts based on
GDB how to stop execution without a breakpoint?
Neither of these have any effect:
pkill -SIGINT gdb
kill -SIGINT 5717
where 5717 is the pid of the only gdb running. Sending SIGINT to the legacy_program the same way does kill it but then I do not get the backtrace:
Program received signal SIGINT, Interrupt.
Quit
How can I programmatically pause the execution of the legacy_program after 10 seconds and get a backtrace?
This post was motivated by my frustration not being able to find an answer to this question here at StackOverflow.
Also note that
[it is not merely OK to ask and answer your own question, it is explicitly encouraged.](https://blog.stackoverflow.com/2011/07/its-ok-to-ask-and-answer-your-own-questions/)
Apparently, it is a known (bug) feature in gdb, see
GDB is not trapping SIGINT. Ctrl+C terminates program when should break gdb. Try sending SIGSTOP instead from the other terminal:
pkill -STOP legacy_program
It works on my machine.
Note that you do not have to run the legacy_program in the debugger. Enable core dumps
ulimit -c unlimited
and send the program SIGTRAP to make it crash, then get the backtrace from the core dump. So, start the program:
./legacy_program
From another terminal:
pkill -TRAP legacy_program
The backtrace can be obtained like this:
gdb --batch -ex=bt ./legacy_program core
I am trying to do a profiling on my embedded Linux box. This is running a software.
I want to do a profiling on my software using strace.
The application is the main software that keeps running forever.
How can I run the strace and log the outputs to a file.
In my rcS script.
I run the application like this
./my_app
Now, with strace.
strace ./my_app -> I want to log these outputs on a file, and I should be able to access the file without killing the application. Remember this application never terminates.
Please help!
Instead of a target filename, use the -p option to strace to specify the process ID of an already running process you wish to attach to.
Chris is actually right. Strace takes the -p option, which enables you to attach to a running process just by specifying the processes PID.
Let's say your 'my_app' process runs with PID 2301 (you can see the PID by logging into your device and us 'ps'). Try doing 'strace -p 2301', and you will see all system calls for that PID. You can throw it to a file by redirecting everywhere: 'strace -p 2301 > /tmp/my_app-strace'.
Hope this helps.
I have a master-workers architecture where the number of workers is growing on a weekly basis. I can no longer be expected to ssh or remote console into each machine to kill the worker, do a source control sync, and restart. I would like to be able to have the master place a message out on the network that tells each machine to sync and restart.
That's where I hit a roadblock. If I were using any sane platform, I could just do:
exec('ruby', __FILE__)
...and be done. However, I did the following test:
p Process.pid
sleep 1
exec('ruby', __FILE__)
...and on Windows, I get one ruby instance for each call to exec. None of them die until I hit ^C on the window in question. On every platform I tried this on, it is executing the new version of the file each time, which I have verified this by making simple edits to the test script while the test marched along.
The reason I'm printing the pid is to double-check the behavior I'm seeing. On windows, I am getting a different pid with each execution - which I would expect, considering that I am seeing a new process in the task manager for each run. The mac is behaving correctly: the pid is the same for every system call and I have verified with dtrace that each run is trigging a call to the execve syscall.
So, in short, is there a way to get a windows ruby script to restart its execution so it will be running any code - including itself - that has changed during its execution? Please note that this is not a rails application, though it does use activerecord.
After trying a number of solutions (including the one submitted by Byron Whitlock, which ultimately put me onto the path to a satisfactory end) I settled upon:
IO.popen("start cmd /C ruby.exe #{$0} #{ARGV.join(' ')}")
sleep 5
I found that if I didn't sleep at all after the popen, and just exited, the spawn would frequently (>50% of the time) fail. This is not cross-platform obviously, so in order to have the same behavior on the mac:
IO.popen("xterm -e \"ruby blah blah blah\"&")
The classic way to restart a program is to write another one that does it for you. so you spawn a process to restart.exe <args>, then die or exit; restart.exe waits until the calling script is no longer running, then starts the script again.