I'm trying to remotely launch and debug a new process with lldb without much success.
Attaching to an already launched process works well by running these commands:
process connect <url>
process attach -P gdb-remote --pid <pid>
But if I want debugserver to launch the executable by itself I'm running into troubles. Especially, I have no clue what arguments should I pass to target create.
According to this page LLDB "will transparently take care of [..] downloading the executable in order to be able to debug", yet target create seem to always require a local file. If I specify the remote file via -r I get either unable to open target file or remote --> local transfer without local path is not implemented yet errors. If I set the target to a local file (such as a local copy of the remote's loader executable) without using -r, then attempt to run process launch -p gdb-remote -s <remote path> LLDB will attempt running the local path on the remote machine and fail.
What are the correct commands I need to use in order to launch a remote process?
After contacting LLDB's mailing list Greg updated the documentation page, which now clearly explains what I have to do (Specifically I was missing the script lines, which appear to be the correct way to set the remote executable path)
Related
I would need clarification on jmeter.bat/sh and jmeter.FIle which are in bin folder.
With example:
1.If i setup different HEAP size in jmeter and jmeter.bat/sh file,which one will be considered.?
2.Does the above depend on how i run the test?(for ex: jmeter -n -t or jmeter.bat/sh -n -t)
3.If the test started with jmeter command instead of jmeter.bat ,will intern jmeter.bat be called and hence heap in jmeter.bat be used or vice-versa?
Update1: Adding screenshot where we can see jmeter/jmeter.bat/jmeter.bat files
You should update one file based on your OS Windows/ Unix
To run JMeter, run the jmeter.bat (for Windows) or jmeter (for Unix) file.
Both execute internally ApacheJMeter.jar
In windows execute jmeter -n -t is actually calls jmeter.bat
In Unix you can call either jmeter or jmeter.sh
Looking into your screenshot it seems that you're running Windows so the only file you should be considering is jmeter.bat
If you want to change JVM Heap it's better to go for changing HEAP environment variables on Windows level like:
set HEAP=4G && jmeter.bat
when you type jmeter Windows is looking for a relevant executable or shell script first in the current folder than on PATH so jmeter will call jmeter.bat if you're invoking it from JMeter's "bin" folder, if you do it from another folder the command-line interpreter will look for it in PATH and if nothing will be found - it'll fail with "'jmeter' is not recognized as an internal or external command,
operable program or batch file."
More information: How Do I Run JMeter in Non-GUI Mode?
I want to run a few shell commands every time I SSH to a server via PuTTY. I'm connecting to a production web server managed by someone else, and I don't want to store my own scripts there.
I see the option Connection > SSH > Remote Command, but if I put my initialization commands there, after starting the session, it closes immediately after the commands execute. How can I run the Remote Command, and then keep the session open so I can continue using it?
The SSH session closes (and PuTTY with it) as soon as the command finishes. By default the "command" is a shell. As you have overridden this default "command" and yet you want to run the shell nevertheless, you have to explicitly execute the shell yourself:
my-command ; /bin/bash
See also Executing a specific command on the server.
One option to go is set up your putty remote command like this:
ls > dir.ls & /bin/bash
In this example command you want to run is "ls > dir.ls" what creates file dir.ls with content of directory listing.
And as you want to leave shell open you can add aditional command "/bin/bash" or any other shell of your choice.
I have a .bat file on my Windows machine. This .bat file uses plink.exe to connect to an Ubuntu machine and execute an .sh script. However, I get different behaviors on the script depending on how Plink is used:
log onto Ubuntu directly (in person) -- script succeeds
ssh via Bitvise client -- script succeeds
ssh via Plink (by calling plink.exe) and calling script from interactive shell (it's a Ubuntu shell within windows cmd.exe) -- script succeeds
ssh via .bat which then calls Plink -- script fails
The script fails w/ message:
error while loading shared libraries: libCint.so: cannot open shared object file: No such file or directory
Other posts seem to refer to installation/permission issues of libCint.so but I know this is not the case since the script works correctly in other instances as shown above.
Below is the plink.exe line from my .bat file:
plink.exe !plink_ssh_details! myscript
The above script fails when called this way via .bat file; again, note that it succeeds when called directly from the Ubuntu or when I -ssh directly into the Ubuntu via cmd.exe (using plink.exe) or Bitvise client. Any help would be appreciated.
In the other cases, you are using interactive sessions.
While the Plink uses non-interactive session by default, when you specify a command on its command-line.
Your script probably relies on some environment variables (like PATH) being set specifically.
It's quite probable that the variables are set only for interactive sessions. Probably because they are modified in a startup script that is executed (sourced) for the the interactive sessions only.
Solutions are:
Correct the startup scripts to modify the variables unconditionally (even for non-interactive sessions).
Modify the script not to rely on environment variables.
Or you can source the profile script, see Unable to run shell script with ktutil command from Windows using PLINK.
Force the Plink to use the interactive session using the -t switch
This is not a recommended solution, as using the interactive session to automate a command execution can bring you nasty side effects. See for example Is there a simple way to get rid of junk values that come when you SSH using Python's Paramiko library and fetch output from CLI of a remote machine?
Some more obscure SSH servers can also behave differently when "exec" channel is used to execute the command. See Executing command on Plink command line fails with "not found".
I had to hack a solution to work around this problem. Adding a "-i" option at the header of the bash script I was invoking from my .bat file did the trick:
#!/bin/bash -i
Note some warn of unwanted side effects (no mention of specifics tho...) when using this option. But calling this now interactive script from a remote ssh session (e.g. when using plink.exe from a Windows .bat file and passing inline commands to the Unix box) solves any issues regarding file/directory visibility & permission issues.
Note to plink users: if you're calling a script on Unix via plink and noticing that the script doesn't behave as expected...adding the "-i" may help debug/solve your problem. Again, note that some have claimed unwanted side-effects of this hack of which they/I'm unaware.
I currently have an Asus c300 chromebook. Since it doesn't have legacy boot, I'm using crouton to get a more standard command line environment. I was able to install gcc very easily in the chroot environment. It works very well under chroot.
Since the underlying hardware is the same, I thought the resulting executable should work for chromebook, without me being in the chroot environment. If true, I thought I could go into the chroot environment, compile whatever program I want/need, and exit back out to the regular environment and use it.
I tried it with a simple hello world program. When I tried to run the executable, I got the following error:
bash: ./a.out: Permission denied.
I tried to run it with sudo, and I get a similar error:
sudo: unable to execute ./a.out: Permission denied.
I even used su to login as root, and I still could not run the program (got the first error).
I thought su/sudo would override any kind of permission restriction. But, it's apparently not the case on the chromebook.
What am I missing? Is what I want to do possible?
EDIT: File permission was already set to 777.
You might simply have to change the permissions of the file or check the files ownership. umask determines weather or not a file that is created gets execute permissions by default. What does -ls -lat on the file reveal?
Also try running
chmod +x ./a.out
You can find more details of error with strace command
use:
strace ./a.out and check output.
I suppose you have different env (path and LD_library_path) under the chroot.
I'm programming application using libpcap. when I debug the application in normal mode, pcap cannot get the network device. it seems that I have to debug the application in root.
How can I debug the application in root? I have the root password.
I think eclipse has such an option that can add root for the debugging application,but I don't know how to do it.
please help.
Enable your user to run gdb as root without being asked for any
password:
sudo visudo
Add the following line after all other rules:
<youruser> ALL=(root) NOPASSWD:/usr/bin/gdb
Create or modify a debug configuration in eclipse to run gdb as root
e.g. in Run > Debug Configurations > C/C++ Application > YourProject Debug:
change Debugger > Main > GDB debugger from gdb to sudo -u <youruser> gdb
Update (and warning!):
In his comment nategoose pointed out that this answer should come with a warning:
Enabling a user to use sudo for gdb like suggested in my answer in fact gives admin privileges to him/her which in many cases might be an undesired side effect. I therefore consider the answer appropriate in an environment where it's not assumed that the user would try to harm the system (e.g. it's your own personal computer or a virtual machine)
For a multi-(non-trusted)-user environment I think it might be a better idead to utilize unix' file capabilities to enable gdb to debug an application without the need of admin privileges
You can use gdbserver on localhost to attach a existing process, the following is the command line:
sudo gdbserver :<listening port> --attach <pid>
Or you can create a new process using gdbserver:
sudo gdbserver :<listening port> <process executable>
Then you can create a debugging configuration in Eclipse, in the debugger tab, the debugger item, select gdbserver, and input the listening port in the connection tab in the bellow.
Launch Eclipse with sudo (just for completeness: http://www.eclipse.org/forums/index.php?t=msg&goto=516838&)
Update: Follow xmoex solution. If you run Eclipse as root (ie. using sudo) your files will be root-owned... which you probably don't want.
Another solution is to grant you (or the gdb executable) the rights to make some pcap captures as mentioned here. With something like this :
setcap cap_net_raw,cap_net_admin=eip /usr/bin/gdb
you should be able to allow to capture packets to gdb without being root.
Here's how I did it:
Create a C/C++ Remote Application
On the target, make sure your sudo does not prompt for a PW
Look at Debug Configurations → Debugger → Port number
Edit Debug Configurations → Main → Commands to execute before application
Change to:
sudo gdbserver :<port number> <path to application>;exit #
This will basically run the gdbserver that would normally be executed by eclipse inside the sudo, the trailing '#' will keep the eclipse command from executing.
this question was asked a long time ago but if this will help to anybody I open a bug in bugzilla and this short thread solved the problem:
bugzilla bug
From the console in the directory with your executable:
sudo gdb ./my_program
If eclipse supports remote debugging then you could do that even though it is running locally.
From the console:
sudo gdbserver localhost:<port_number> ./my_program
And then tell Eclipse the address (localhost and the port number you chose).
Oh yeah, you said the reason you were doing this was because you were using libpcap, so you may not want to use remote debugging over TCP because you may end up capturing your debugging connection packets in addition to your other network traffic.
In that case you do your remote (but really local) debugging over a serial port. I have never done this on a local machine, but you could use two actual serial ports (attaching them though a null modem) or try using a psudoterminal:
sudo gdbserver /dev/ptmx ./my_program
This will create the psudo-terminal under /dev/pts/ but you'll have to figure out the name of it, and it might also create it with restrictive permissions. You can get around those. Unless you are running lots of terminal windows as root, it is not likely that you have many entries under /dev/pts that belong to root, so take note of the one that does after running the above command and then sudo chmod or sudo chown it to make it usable for your normal user and then tell your debugger to use that as your serial connection to your remote debugging target.
easiest way, try sudo ./eclipse, then debug as usual