In the testing I'm doing I have noticed that (both with blocking mode):
On Linux ssh_channel_read_timeout when command timeout answer 0 (readBytes).
On Windows ssh_channel_read_timeout when command timeout answer -1 (readBytes).
Both call the same function ssh_channel_read_timeout.
Also:
On Linux ssh_channel_is_eof answer false when command timeout.
On Windows ssh_channel_is_eof answer true when command timeout.
Any hint about this different behavior ?
Or is there any effective way to detect when a timeout has been triggered ?
The command that is executed is very simple: sleep 1 | free -m
Related
I have the newest (2020.3 EAP ATM) version of CLion and I currently use it to remote debug a program on an embedded target (linux-mipsel).
Everything works as expected, after a bit of configuration, using self-built cross-toolchain and gdbserver.
My only problem is hitting the "red square" to stop execution will neither kill the running program nor gdbserver itself.
This means next iteration of edit-compile-debug cycle I will have two copies of both (I can get more, if I insist) which will not work as each tries to open the same resources (e.g.: a serial port) concurrently.
I have to manually log into target and kill the offending processes.
Am I missing something, is it a known bug or what?
Small update:
gdbserver is actually killed (does not show in ps ax) but underlying program (debugee) is still there. I am unsure why I was convinced otherwise, my bad.
This is a known issue and will hopefully be fixed soon.
Here is the link to the youtrack issue: https://youtrack.jetbrains.com/issue/CPP-20346
You could try the suggested workarounds:
Add pre-deploy configuration which kills running instances of the program
Follow the instructions for the gdb configuration in the comments:
GDB Server: /bin/bash
GDB Server args: -c "gdbserver :1234 /home/pi/myapp; pkill -e myapp"
The second config did not work for me, so I added the execution of an external tool where I run in /bin/bash the command -c "pkill -e myapp || true". The true is mandatory to avoid errors if the program is not running.
I have developed a c++ app that runs on debian jessie server. Since I'm quite new in linux distros and specially the server ones that provide only terminal, I 'd like to find out if there is a way to watch the %CPU and %MEM on the same time that the c++ app runs. I tried to run
./C++_APP & ps -aux | grep .C++_APP
but ps ran only at the beginning. Is this possible somehow either with ps or with another command?
Use watch. You can pass your ps (along with its arguments) to it. If you don't run your application as a background process you will have to use a second terminal session or pipe the results to a file that you can look at later on.
You can use/install htop.
Set filter to match your executable name.
You may try that:
./C++_APP & wait && PID=`pidof -s -x C++_APP` && top -b -p $PID
It will display stats every second.
To break CTRL+C
To kill your app type than
kill $PID
I was trying to call powercfg tool from my 32-bit application running on a 64-bit version of Windows 8.1 using CreateProcess with the following command as lpCommandLine parameter:
"powercfg -waketimers"
It worked fine, except that purely by chance I discovered that it was returning a different looking report than if I ran the same from the Command Line window.
Here's what I was getting in my 32-bit process:
Timer set by [PROCESS] Legacy Kernel Caller expires at 4:00:02 AM on 1/20/2016.
Reason:
Timer set by [PROCESS] Legacy Kernel Caller expires at 3:59:00 AM on 1/20/2016.
Reason:
and here's what I was seeing in Command Line window:
Timer set by [SERVICE] \Device\HarddiskVolume4\Windows\System32\svchost.exe (SystemEventsBroker) expires at 4:00:02 AM on 1/20/2016.
Reason: Windows will execute 'NT TASK\Microsoft\Windows\TaskScheduler\Regular Maintenance' scheduled task that requested waking the computer.
Timer set by [SERVICE] \Device\HarddiskVolume4\Program Files (x86)\Common Files\Acronis\Schedule2\schedul2.exe (AcrSch2Svc) expires at 3:59:00 AM on 1/20/2016.
So I'm curious, are 32-bit and 64-bit versions of that tool supposed to return different results? Because the only way I can remedy this and get a full report (2nd version above) from my 32-bit process is to detect it running as WOW64 and then use the following path for a forced 64-bit redirect:
"C:\\Windows\\SysWow64\\powercfg.exe -waketimers"
I am writing a program that logs into another system via SSH using the libssh2 library. Once logged in, I execute a command using:
libssh2_channel_exec(sshchannel, command)
The command executes okay. However, once I close the channel the process running is killed. In my case, the command (executing a binary executable) will run for a long period of time and my program cannot wait for it to terminate. I've tried issuing the following commands all to the same result (the process is still killed upon closing the channel):
/path/myprog
nohup /path/myprog
nohup /path/myprog &
/path/myprog &; disown
Further, I've observed this behavior for both libssh and libssh2. Is there some option or command I am missing?
Thanks in advance.
you can use the unix at command:
echo "cmd" | at now
I am remote debugging a Stellaris Launchpad. I use OpenOCD to connect to the stellaris and then connect GDB to the server provided by openOCD. I use Open On-Chip Debugger 0.10.0-dev-00002-g79fdeb3 (2015-07-09-23:28). GDB is the one from arm-gcc-none-eabi, the 4_9-2015q1 release.
I invoke openOCD like this:
/usr/local/bin/openocd --file \
/usr/local/share/openocd/scripts/board/ek-lm4f120xl.cfg \
>> openocdLog.txt 2>&1 &
And then GDB like this:
arm-none-eabi-gdb proj//debug/exec -x gdb//gdb.script
gdb/gdb.script contains:
set remotetimeout 10000
target extended-remote :3333
monitor reset halt
load
monitor reset init
The problem is that whenever I hit control+c GDB disconnects. Normally this would halt the remote, but GDB just disconnects:
(gdb) cont
Continuing.
^CError detected on fd 6
Remote communication error. Target disconnected.: Interrupted system call.
(gdb)
OpenOCD has the following things to say, this one while GDB is launching:
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1258). Workaround: increase "set remotetimeout" in GDB
Which is weird, considering the gdb/gdb.script file forces remotetimeout to an insanly large number.
And when pressing control+c openOCD says:
Debug: 2602 5089 hla_interface.c:119 hl_interface_quit(): hl_interface_quit
So, how do I resolve this? How can I make GDB halt the remote instead of disconnecting when pressing control+c?
The problem was OpenOCD being too bleeding edge. I had issues with 0.6.1, but version 0.7.0 of OpenOCD works great.