I'm using dev_appserver.py to run my Go App locally on my Ubuntu machine. I'm trying to debug the application but can't seem to find the go process to attach a debugger to. Can anyone point me in the right direction?
The process you are looking for when running the go-appengine-sdk using the google-cloud-sdk is _go_app. Simply modifying my app to start with a NoOp infinite for loop was enough to send it to the top of the CPU usage list so I could find it.
So on Ubuntu, a simple ps aux | grep _go_app should list the PID.
P.S. This was done on a Mac, so it's possible (however unlikely) that it could be different. But doing your own NoOp for loop to find it would work anyway.
Related
Following https://docs.hiro.so/smart-contracts/devnet I can't get the command clarinet integrate to work. I have installed Docker on my mac and am running version 0.28.0 of clarinet. Running command within 'my-react-app/clarinet' where all clarity related files live (contracts, settings, tests, and Clarinet.toml).
My guess is it could be an issue with Docker?
The issue was that I downloaded my Devnet.toml file from a repo that was configured incorrectly. The configuration I needed was:
[network]
name = "devnet"
I increased the CPU and Memory in Docker as well.
There is an issue when the command attempts to spin up the stacks explorer, but I was informed that there are several existing issues with the stacks explorer from clarinet integrate at the moment.
Depending on how the last devnet was terminated, you could have some containers running. This issue should be fixed in the next incoming release, meanwhile, you'd need to terminate this stale containers manually.
Apart from Ludo's suggestions, I'd also look into your Docker resources. The default CPU/memory allocation should allow you to get started with Clarinet, but just in case, you could alter it to see if that makes a difference. Here's my settings for your reference:
Alternatively, to tease things out, you could reuse one of the samples (eg: hirosystems/stacks-billboard) instead of running your project. See if the sample comes up as expected; if it does, there could be something missing in your project.
I would like to make a Graphical interface for a home-made program using SFML on Raspberry Pi2. I am using Raspbian. I recompiled the graphical lib
It works fine unsing startx first, then using my application, which wors perfectly fine.
But I can't figure if it is possible or how to launch my application directly after boot without launching startx (just to optimise the cpu of the Raspberry).
Starting my program direcly after boot, I get the following error:
Failed to open X11 display: make sure the DISPLAY environnement variable is set correctly.
Aborted.
I already tested the classic export DISPLAY=:0.0 but without sucess.
I interested myself in x and xinit, but I am not sure that would even do it.
Where should I start looking? I don't need a complete solution, even a hint or an idea would be nice!
I checked to see if it was possible to open a graphical app without the X desktop environment and as that answer states, with Firefox at least, you need the X server which SFML also probably needs in order to create a window.
The answer states:
Basically something like:
$ X
Then you just start Firefox in this X server:
$ DISPLAY=:0 firefox
You can switch from the X server and the framebuffer by using
CTRL+ALT+F1 and CTRL+ALT+F7.
You could try that and see if it helps.
Also, still searching, I found a forum post on the sfml website about what you're trying to accomplish stating somewhere:
SFML requires OpenGL, so as far as I know you need at least X running,
but you probably don't need gnome, KDE or a similar Desktop
Environment on top.
The forum guy asking for help seems to have managed to get X11 and a SFML basic render window to work on Ubuntu server after someone posted a link to xinitrc. I guess, that's the route to go from here.
I'm trying to debug for the first time a gtk code and actually, I want to debug a callback function for key-press-event so I set a breakpoint with gdb and when it hits the breakpoint, the whole desktop evirement is freezing (I'm running under gnome-shell) it seems that the graphic envirement is waiting for the event to finish.
I got some idea that didn't worked :
The first attempts was to assign some gdb commands to the breakpoint :
(gdb) break on_key_press_callback
(gdb) commands
> back trace
> next
> next
> next
> continue
> end
but I don't know why, only the back trace command is executed, and then freeze.
The second attempt was to debug remotely using gdbserver and gdb on tty1 (no graphigs to freeze :) ) I was able to send commands like next and step after the breakpoint but there was nothing to see (can't list code, inspect the stack, ect ...)
So any good tips to be able to debug in such situations ?
Thanks
It's typical to have lockups when debugging an X program running on the same server that you're using to debug. For example, if the inferior (gdb terminology for the program being debugged) does a server grab -- whoops, the gdb GUI (or terminal or emacs etc) is locked out.
Your idea of doing more programmatic debugging is a good one, but it's hard to make it all work nicely. As you found, some gdb commands (basically those related to inferior control) don't work in commands. Also, it just isn't nearly as convenient.
You can go further that direction. For example you could use SystemTap to probe the program instead.
However there are also nicer approaches.
One way is to run the inferior using a virtual X server -- a nested one, or one running in a VM. Then you can escape to the "outer" X server for debugging. This will be much nicer.
Another way is to have two computers, and run the debugger on one and the inferior on the other. In a way this is really the same answer, just using a real machine rather than a virtual one.
The question is old, but for anyone that may be struggling with this issue, there is a way to stop the freezing behaviour from happening by disabling the X server grab.
You have to change the config in your IDE to run the program with the following system property:
-Dsun.awt.disablegrab=true
If you are using javaws (Java Web Start) to run the application use:
-J-Dsun.awt.disablegrab=true
instead.
I"m (slowly) working on a app-engine app using the go language -- While I like many parts of the experience (the nice integration with google services and the go language itself) but I'm a bit suprised at the lack of debug facilities especially with app engine.
I know that you can log to the console (The lowest form of debugging IMHO) but all attempts at anything more clever (attaching gdb on the local instance) fails. (the build tools for app engine specifically seem to strip debug info)
I can't believe I'm the only one who has observed this so I'm wondering what other folks are doing to develop/debug in app engine?
There is not currently a better way than context.Errorf() and friends. Python just got pdb support in the 1.8.3 SDK. I have not heard of any similar debugger support for go. It is perhaps worth asking on the app engine go list about this.
I just red about your topic in this blog:
http://joshua.themarshians.com/hardcore-google-unit-testing.html
I can't give you an example but maybe it will help.
it's been an update and I thought to add what is the current state of affair.
The good news is the go tools now no longer strip debug symbols so if you are running on your local machine you can now get gdb support!
It's a bit of a process and ripe for some more automation (suggestions welcome)
in short:
look for the _app_go process
cd to the directory that it's running from
Attach to the process with the '-pid' command to gdb
Tell gdb the directory of source
Boom -- debugging.
How exactly would one go about getting an OpenGL app to run fullscreen straight from the terminal (Ubuntu Server 9.04)? I've developed an application for visual diagnostics on my server, but, I'm not totally sure the best way to get it to run in a windowless environment.
Ideally, I would run my program:
./visualdiagnostics
and have that launch the OpenGL app. Then, via a simple Ctrl+X key binding, I'll kill the app and go back to the terminal.
Do I need to install X11 and then somehow launch it from within the program? What would be the best way to detect if it's already running and, start/stop it if necessary?
And FYI: No, I'm not trying to get this to run over Putty or anything... I have a monitor hooked straight up to the server. The server has proper video drivers installed.
There are several parts to your task. Keep in mind that some of this can be very distro-specific; but since you said Ubuntu we'll talk Ubuntu!
Also you tagged this question C however I am starting off with a common Linux pattern: a native application with a Bash shell script wrapper. Perhaps once you get things working well you might fold that functionality into C if you have to.
Detecting whether X is running
Being root can help a lot. Some things that work.
pgrep Xorg
Check whether /var/lib/gdm/:0.Xauth exists. This will be there even if nobody has logged in but GDM is running.
ls -l /home/*/.Xauthority (Even if you're not root you can at least confirm whether you are running X.
Piggybacking an existing X session
You did not specifically mention it but if you are root at the console, or if you want to run the app as the same user who is already logged in, it's pretty easy.
You have to get the DISPLAY and XAUTHORITY environment variables right, and once you do you can use the existing X display.
For DISPLAY you might just assume :0 or you could find an existing X program (x-session-manager is the GNOME standard) and read its environment from /proc/PID/environ. Variables are in key=value format delimited by a null byte. For example, if its PID is 12345:
cat /proc/12345/environ \
| ruby -ne 'puts $_.split("\0").select {|e| e.starts_with? "DISPLAY=" }'
For XAUTHORITY you could get it the same way. Or if you prefer guessing, it's almost always /home/whoever/.Xauthority
Once you have those two variables, running X code is easy, for example:
env DISPLAY=:0 XAUTHORITY=/home/brian/.Xauthority ./visualdiagnostics
Stopping X
This one is easy if you're root: /etc/init.d/gdm stop. killall Xorg will work too.
If you are a user, kill your own Xorg or x-session-manager process. (I'd welcome input from others for the canonical way to do this. Maybe some dbus-send message?)
Starting X
I would recommend xinit whose goal in life is to fire X and run exactly one program.
For example: xinit ./visualdiagnostics
You can also tell xinit what resolution to run X at which may or may not be important to you. (This becomes important in the full-screen section below.)
The problem with this is you will have no window manager— no maximize and minimize buttons. It's not just cosmetic. Usually an app is useless because a popup window cannot be moved or you cannot focus on the right input field. However if you have a special app it could be sufficient (see full-screen below).
The next step would be my answer to everything: another shell script wrapper! Something simple that starts the window manager and then becomes your program should work.
#!/bin/bash
#
# Start visualdiagnostics once xinit calls me.
/usr/bin/metacity& # Or ratpoison, or fluxbox, or compiz, etc.
exec ./visualdiagnostics
It's important to exec (become) the main program because once that first program exits, X will shut down.
Running fullscreen
I am not 100% certain on this. Some ideas:
Try the standard X -geometry parameters to set 0,0 as the upper-left corner and +x+y for your horizontal and vertical size. How do you know the size? Either you hard-coded it when you launched xinit or you could ask the X server. xwininfo -root will tell you and there is an xlib API call that would do that too—check the xwininfo source I guess.
Your app itself can request maximization and/or resizing to fill the screen. I'm not familiar but it is definitely in the X API.
Some of the more configurable window managers can be pre-configured to run you maximized already. This is probably what I personally would check first. Your wrapper script could create a $HOME/.fluxboxrc just by echoing some hard-coded configs > the file.
Summary
The others are right. X is not strictly necessary sine OpenGL can run against a framebuffer. However considering how ubiquitous X is and how much work has gone into automating it for distributions, I would probably invest my effort into the X route as it might be easier long-term even though it's a little convoluted.
(By the way, I sincerely hope when you say "terminal" you mean you are at the text console, not gnome-terminal that would be awful! :)
Well I am clearly not sure my answer might help you out.
Long ago when I was student, I manage to do so (launching an openGL app from a terminal only linux installation) by installing frame buffer. As long as I remember I needed to recompile my kernel (as framebuffer was/is a kernel module).
This was maybe 5 years ago on a debian distrib, and I don't know how does it work now for up-to-date debian distrib as Ubuntu. Maybe framebuffer is compiled statically in the binary kernel provided by default with Ubuntu. May be not. Maybe framebuffer is irrelevant now... Or I may be totally wrong and not remembering every details of my own adventure 5 years ago now ..
Have a look on Google ! ;-)
Hope it will help...
**
Update:
**
What is frame buffer ?
How to install it? Here or there
As yves pointed out, you can avoid running the X server if you use the framebuffer. Actually, the framebuffer modules are often yet available (for example, they are used to have the tux logo during the kernel start or a text terminal with fancy images in the background), this anyway depends on the distribution and the settings you are using.
The kernel side is quite primitive so I'd suggest to use some higher level library such as DirectFB. The framebuffer is usable without problems but don't expect the same maturity level than a full blown X server.
Are you trying to have the video be on the monitor connected directly to the computer?
Is X running on the server?
If X is running, you can do
export DISPLAY=:0.0
which tells X apps to connect to the X server at localhost, rather than where' you're coming from.
If you're actually logging in locally (from a direct terminal) ... yes, you need X installed and running.