At present we are developing a graphic app on a linux box using opengl. We have had a bit of trouble getting a decent debugger working. At present we use GDB via a ssh connection, but that is a tad painful. Next we have tried running DDD on the target platform, but we run out of space on screen. Next we have tried running an xserver via cygwin on windows and doing an "export DISPLAY=RemoteHost:0.0" on the linux box. In this situation DDD will run on the windows box, but when we boot the app it also wants to pipe its output to the windows box.
What we really want to do is have DDD output on our windows box, and the output of the main app on the linux box.
I am not a x11 guru and I would love some help in this area.
Cheers
James
While logged in into the linux box:
DISPLAY=windows-box:0 ddd /path/to/app
DDD should now pop up on your windows box. If you run the app at that point, it will attempt to display on windows box as well, since the DISPLAY environment variable is inherited. You need to reset it:
(gdb) set env DISPLAY :0
(gdb) run
At that point, the app should display on the linux box, as desired.
Many applications accept -display command line argument. If yours does, an alternative is to do this:
(gdb) run -display :0
instead of resetting the DISPLAY environment variable.
Related
I've been playing with VirtualBox implementations of Xubuntu. I'm learning provisioning test boxes with content using both VBoxManage and Vagrant. Unfortunately my boxes work very erratically. I'd like to enable the debug mode in VirtualBox to better understand why the boxes sometimes freeze up.
Current top menu: VirtualBox VM / Machine / View / Input / Devices / Window / Help. I'd like to be able to get to the / Debug / top menu with its selection of Statistics / Command Line / Logging / Show Log as displayed in the VirtualBox Graphical User Input (GUI) tool, [select Virtual Machine --> Settings --> User Interface.]
As I understand it, I'm looking for the Built In Debugger. I've found the instructions, but they don't make sense to me.
The debugger can be enabled in three ways:
Start the VM directly using VirtualBox --startvm, with an additional
--dbg, --debug, or --debug-command-line argument.
Set the VBOX_GUI_DBG_ENABLED or VBOX_GUI_DBG_AUTO_SHOW environment
variable to true before launching the VirtualBox process. Setting
these variables (only their presence is checked) is effective even
when the first VirtualBox process is the VM selector window. VMs
subsequently launched from the selector will have the debugger
enabled.
Set the GUI/Dbg/Enabled extra data item to true before launching the
VM. This can be set globally or on a per VM basis.
I know how to start my virtual boxes in two ways. 1) Open the Virtual Box GUI, click on the machine of interest, then start it up. 2) Start the box up from the folder that contains my custom Vagrantfile, then $ vagrant up.
Its not clear to me from the above link on Virtualbox, how to set up vagrant or VBoxManage or VirtualBox GUI to start up a box with Debug mode enabled (or better yet, enable Debug mode when building a custom box...). I can't believe someone built up a nice GUI then omit the chance to implement Debug into the tool.
Note: I'm using MacOS for my host; I've had best luck using bstoots/xubuntu-16.04-desktop-amd64 as the base for my guest virtual machine box. Anybody been here before? Tips and hints as to how to start a box with debug enabled? Many thanks.
So I tried few more things (Virtual Box 5.2.20 r125813 on 64-bit Win7 Enterprise).
Method 3'' (per machine ExtraDataItem: does NOT do anything, even does not add 'Debug' menu to the VM window)
Method 3' (global ExtraDataItem): adds 'Debug' menu to the VM windows but does not break at the VM start (VM is just running, you can open the debug console and stop it but then of course we are deep into the boot process, or after...). But it could be useful ... no harm of having 'Debug' as a default.
Method 1: Works BUT not as described, even in the VBox own User manual is confused, page 261 describes the options WRONG. However the chapter 8 gives some ideas, here we go:
you can add the environment variables to the command line:
C:\Program Files\Oracle\VirtualBox>vboxmanage startvm "SomeVM" -E VBOX_GUI_DBG_AUTO_SHOW=true -E VBOX_GUI_DBG_ENABLED=true
will show the 'Debug' menu, open the debug window and load the VM halted at the reset vector
VBOX_GUI_DBG_ENABLED=true
alone will just add 'Debug' to the VM's window (the VM will run)
VBOX_GUI_DBG_AUTO_SHOW=true
alone will load VM halted but no 'Debug' menu so really nothing to do ... (however this can be paired with the global setting!)
The remark in the manual (and online) that the variables have to be only defined is NOT true, unless set to "true" they do not have any discernible effect.
BTW: the ExtraDataItem line is:
<ExtraDataItem name="GUI/Dbg/Enabled" value="true"/>
I decided to set it up: this way all the VMs have the 'Debug' menu enabled but start as usual, if I want to debug one from the start then I use the command line with
-E VBOX_GUI_DBG_AUTO_SHOW=true
https://reactos.org/wiki/VirtualBox#Built-in_VirtualBox_.28low-level.29_debugger explains things a little better, however only for Windows (I presume 7 ...). There are 3 methods:
1 - Start VBox from the command line window adding the options as listed (see the VBox User manual for the command line method of running). The advantage that it is per machine, disadvantage: the command line is long and best issued from a shell script (in case of Windogs: BAT or CMD).
2 - Declare the environment variables:
I tried some under Windows 7 (64-bit Enterprise), here I declared User environment variables VBOX_GUI_DBG_ENABLED and VBOX_GUI_DBG_AUTO_SHOW (Computer / Properties / Advanced System Settings / Environment Variables) and after restarting Virtual Box GUI when I started the VM it would come to the debug console. My VM was x86_64 and like many other kernel debuggers this one was quite useless for stepping through ROM BIOS (at least the initial portion). I am too lazy to see if I can set the break-point either after the ROM BIOS is RAM-ed (relocated to RAM) or in the boot-loader (1st I would have to find if and how this VM relocates BIOS and then where would be the best place to break into the boot-loader, which is custom); but I did things like that in the past with similar debugger (this seems to borrow stuff from the oled Compusoft's CodeView x86 kernel debugger ..).
3' - Modify VBox global or per-machine configuration files, I have not tried that but I tracked the global file:
%homedisk%:\Users\%username%.VirtualBox\VirtualBox.xml
it is pretty straightforward, I assume adding the listed item shoudl work (%homedisk% is usually C, substitute %username% for the login name).
3'' - Modify the indiviual VM's file (*.vbx). They VM's are in %homedisk%:\Users\%username%\VirtualBox VMs
The *.vbox files are XML format and find where to add the data is also simple. This method has advantage of being perVM, disadvantage of possibility of screwing the VM up (so make a backup)
I have VirtualBox on my home iMac but I have not tried this yet. I did not dig into VirtualBox on Mac file structures, but I would be surprised if they were not somewhat analogous to Windows. The command line should be pretty similar (paths of course would be different, and the shell script too), one possible annoyance might be that you may have to use sudo ...
Regardless of the host, debugging the initial boot sequence of x86_64 is not trivial because usually in the beginning we time-travel to 80s and pretend that we are running 386 with two cascaded PICs and the extended address lines controller by a keyboard controller ... lots of fun! (or not ...)
I need to know if a program exists ( or if I can create) that runs that computer's command prompt from a USB, without having to log in. I guess I don't really care if it is that computers cmd, but I need all of the modern functions of today's cmd. I also need to make sure that it has full administrative privileges. I know that it is possible, because just about every Linux system uses a similar system when it initially boots up, even when just downloaded to USB.
I guess I really need something that I can use with multiboot (a pure ISO file, not something like Rufus, which requires you to format usb). I don't know, but I don't think an ms dos thingy would have all of today's commands in cmd.
Any help much appreciated. Piece.
Edit: I just need the equvolent of single user mode in a Mac. Administrative access to the terminal without login info.
You can boot windows to safe mode limited command prompt, or you can launch a cmd window via the startup group (but you can't get a full screen after XP and the window can be closed with the latter method).
That is the first issue for you to solve, and then you can consider booting from USB.
I'm currently developing on a automated info-system which is based on a self-written node-service which is also starting a firefox. This system should run in ubuntu without any controlling of anyone.
My current problems are lying in the autostart of the xServer and our own Service.
I created init.d-scripts which are working and linked in the rc-folders bei rc-update defaults etc.
(Xserver is started by startx in init.d)
The xServer is shutting down when reaching the login-screen of debian (without any gui) and the firefox in our service is reporting that it couldn't reach the display.
Sometines the xServer keeps running but there is no chance reaching it by programs with gui.
Is there a chance to run these setup?
Greetings and a happy new year,
Moritz
First you need to get rid of the X display manager being autostarted, that would be the xdm, gdm, kdm, leightdm, lxdm or something like that.
Then don't forget, that Linux manages its console as VTs (virtual terminals). You can tell the Xserver by the vt parameter on the command line, which VT to run on. Note, that the vt parameter doesn't has an option dash, e.g.
Xorg :100 vt14
starts the X server on VT 14. Now it can happen, that some other process switches the VT. So it might make sense to have some watchdog script, that switches back to the choosen VT if on the currently active VT nobody has been logged in (for maintenance for example). To switch a VT use the program chvt. And to make sure, that maintenance sessions are not forgotten open you can use some idle-detection program.
Here is what I want to do:
I want to run Mathematica on another Mac from my Mac (both Snow Leopards). I want to do this because the remote Mac has multiple cores/processors while my local Mac is rather shabby. I would like to have the front end still locally (i.e. the graphical interface).
What I've learned:
I used to do this type of thing from multiple Linux machines and was expecting to have similar success for Mac-to-Mac operation. However no such luck.
The problem seems to be a display issue (front end).
Mac front end runs in Aqua while X11 is what is really needed (this is why there is no problem on Unix). While Macs have X11, for some reason Mathematica can't use it.
So how do I get around this issue?
Possible solutions that I have had to rule out are: 1. screen sharing. Not practical since someone else will be using the remote Mac on another account. Screen sharing only uses the active screen. 2. Installing Unix on the remote computer. Not possible in my situation.
Thanks.
You should be able to set up a remote kernel on the other Mac. This is done through the Evaluation > Kernel Configurations menu item. The you can set the remote kernel for a given notebook using Evaluation > Notebook's Kernel or globally via Evaluation > Default Kernel.
I haven't done this in a while, and it's sometimes useful to test things from a terminal with something like
ssh <user>#<remote.machine.com> </path/to/remote/Mathematica.app/Contents/MacOS/MathKernel>
Why not use the command line kernel? I have a script math which does:
#!/bin/bash
rlwrap /Applications/Mathematica.app/Contents/MacOS/MathKernel
I built rlwrap from source, but basically that tool gives you readline behaviors. You can just do
ssh remote-machine /Applications/Mathematica.app/Contents/MacOS/MathKernel
The only solution, I believe, is for you to upgrade to OS X Lion. It allows simultaneous screen sharing sessions where each user can control the screen for their own account:
http://www.apple.com/macosx/whats-new/features.html#screensharing
I have an HTPC (with an HDTV as the monitor) running Ubuntu Karmic, and various other computers in the house. Sometimes I want to run X11 applications (usually, but not always, XBMC) on the HTPC displayed on the HDTV, but I don't want to have to physically go to the HTPC to do so; I want to do so from another computer in the house.
If I use ssh then, of course, the applications don't run because X isn't started on the connection. I don't want to use ssh -X or ssh -Y because I don't want to forward the display to my laptop: I want to do things in the X session already running on the HDTV. I don't want to use VNC or its ilk because sharing a 1080p display over an 802.11g network is nobody's idea of fun.
What I want is a command to run in a remote bash shell that executes in the local X session. Any ideas?
Try looking into the "xhost" command
Seems like I recall, 20 years ago, "xhost +" or something like that would cause your local X server to accept all incoming requests to create windows on the screen or grab input devices.
This is probably still reasonable to do only if you are behind a home firewall.
On the machine that actually runs the program whose display you wish to forward, you specify a -display option or DISPLAY env variable to forward the graphics window.
X security has changed in the past 20 years, I'm sure... so this may or may not work for you -- but I notice the xhost command is in my ubuntu 9.10