We have our code and binaries in Unix box .Few of the binaries are for web packages loaded by CGI .I use gdb in remote debugging mode to debug normal binaries but web binaries are difficult to debug because the process id changes every time the binary is loaded and gdb detaches .I heard in Visual studio there is a option to add in task manager and debug it .But i m afraid if i install Visual studio my system would go slow.Any suggestion on any other opensource tools available for efficient remote debugging of web binaries
The best thing you can do is to efactor the code so you can test most parts of it outside a CGI context with some unit testing system or something similar.
The second step would be to replay the CGI communication manually. It's not complicated - set the environment variables needed and eventuelly pipe the POST data in while running under gdb.
If that doesen't help you have to debug the web server and ask your debugger to follow child processes. Best thing is to start the httpd using the -X option so it runs with a single process itself. Then attach gdb and set the set follow-fork-mode child command. See gdb manual at http://sourceware.org/gdb/onlinedocs/gdb/Forks.html
Related
I am working on a repository where I have to extract some features from millions of files.
For me, the current workflow is:
Write code in IntelliJ
Run unit tests
Dry run with small data
ssh to the remote machine
sftp the current code to the remote machine
Run on the server with all million of files
Look into the log exceptions and find out where the code is failing for edge cases
Fix those issues and repeat from step 1
My question would be three-fold:
Is there an easy way how I can sync code with the remote machine automatically (I know I commit to git and then pull the changes in the machine. But is there some other way other than setting up rsync etc.?)
Can I run code directly in the remote machine from IDE and debug it that way?
1) There are a lot of ways to sync your code. Sometimes the best way is to create a kind of deploy script in Python or sh if you don't want to commit and push any changes you are going to test on server. You can use sftp or scp with more automation here (use gzip and so on). Git and rsync are more mature solutions here. But with VCS your problems will be more reproducible and easier to find.
2) You can connect to remote process to debug it directly from IntelliJ. There is a official tutorial for that: https://www.jetbrains.com/help/idea/tutorial-remote-debug.html (but it depends on your security settings because Java debug protocol is not secured itself, you may need to setup SSH tunnel for that)
3) Another, a bit more radical option: you might run IntelliJ IDEA itself on server and debug directly. You can use Projector - an open source project which lets you run IntelliJ on the server with UI in the browser (no X11 required to run). I recommend you look at this repo firstly https://github.com/JetBrains/projector-docker or configure IntelliJ on server following instructions here: https://github.com/JetBrains/projector-server.
I'm attempting to automate the build of a source controlled MS Access application (it's only the front-end, the back-end is SQL Server). The Access client is published to the users via a simple C# console app via ClickOnce... It's in that console project that I'm also building the MS Access application via a custom msbuild tasks from this CodePlex library: https://buildmsaccessdb.codeplex.com/ (which is also mentinoed in another StackOverflow post on the subject). On my machine, it all works fine. The Access source code is compiled into an ACCDB, which is then converted into an ACCDE which is what gets included in the published app.
However, when I make it an automated build in TFS, it always stalls at the step where it converts the ACCDB to an ACCDE. I've tried a variety of ways for executing the "Make ACCDE" (SysCmd 603) command. I've tried it in powershell scripts, in VBA, etc... but it always seems to stall. Is that because the automated build process is not an interactive process and maybe the the SysCmd 603 needs to be ran interactively? If I stop the build and take a look at the ACCDB, everything is good. It compiles and can be manually compiled into an ACCDE... so it's not that the ACCDB isn't compilable.
I'd like to test it as an interactive TFS service but I don't control the service account it's running under.
Any tips on suggestions are welcome and thanks in advance! We have this whole automated build and release process up and nearly working except for this one piece!
I don't know much about the MSBuild task library, but from a quick look at the source it looks like it opens Access to run the tasks and interacts with a dialog box at one point. If that's the case you'll definitely need to run the build in interactive mode.
The fact that your build is hanging and not erroring out would also indicate this is the case.
Even though you don't control the service account, I would presume there's someone else in your organisation that does. I'd suggest you work with them and to try the build in interactive mode and ensure it works. If needed you could always set up a second build machine that runs in interactive mode, with the current build server remaining in "run as a service" mode.
I am looking for something similar to RStudio-server (r-studio), but for programming in Java/Scala.
RStudio-server accessed via web is the same as the desktop version.
May be there are other equivalent solutions, given that my problem is scarce local resources to run my programs, but plenty of resources in a remote computer.
The more seamless, the better.
It would be also good if I could just run my program remotely seamlessly (outputing like if it was local and inside the IDE).
I recently starting using Chromoting to remote into a different machine that has IntelliJ. It's convenient in that it's built into chrome and I can pretty much do this anywhere because everyone has Chrome these days. It's a very good remoting tool but it still is remoting, it has its delays and minor problems (some keyboard shortcuts don't get sent through and those options haven't been added yet).
Just an idea for something to try.
It is not seamless, but I just managed to solve the problem using the right workflow:
In the local machine:
edit files in IDEA
[optional] set the output path, if any, to your favorite file hosting service (dropbox in my case)
commit with your favorite VCS (bzr in my case, it can need a push to the remote machine)
In the remote machine:
update with your favorite VCS
compile and run with your favorite build tool (sbt in my case):
sbt 'run-main experiments.AtomicBombMain'
[optional] In the local machine again:
[optional] get the generated files at the output path at the shared folder of your favorite file hosting service
Link with more details about the entire process since instalation until compiling:
sbt-intellij-idea-scala-debian-wheezy-how-to
If I F5 a Windows 8 JavaScript app and look at the processes pane in VS11, I see that it's WWAHOST.exe that I'm attached to. Is it possible to attach to this after the fact using Debug | Attach to Process? I don't see it in the process list even when I show processes from all users. I see the same thing whether I run locally or in the Simulator. Thanks.
There are effectively two ways to do this. Delay starting the app and attaching the app. You will need to install the remote debugger from Microsoft. As of this writing, it is located on http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28973
Detailed steps plus explanations are here.
Summary:
Install VS remote tools
On start menu, launch "Debuggable Package Manager" (powershell will start)
using powershell: get-appxpackage (to locate your package)
using powershell: enable-appxdebug PackageFullName
Launch application
Attach to the correct wwahost.exe for your application.
Debugging Topics Located here.
I have an external Windows .exe that is actually Java application: Running the .exe starts javaw.exe, which in turn runs that Java application.
I didn't write that application and have no access to it through an API. I need to be able to kill it, however. So right now I just kill the Windows process javaw.exe, which is fine for a test machine running only that Java application but if I need finer granularity, I cannot currently do so.
My searches yielded suggestions such as Sysinternal's Process Explorer or the jps command in the JDK, but in the target systems for which I intend to provide the script, neither JDK nor Sysinternal's Process Explorer can be running.
Is there any other way that doesn't require an external tool? Does javaw.exe have a switch or command line option that lists Java processes? Is there a JRE version of jps?
Thanks.
I'd still suggest just killing the javaw.exe.
I can't see the downside, since it is the process you want to kill after all.
Remember that if you run multiple applications on the machine, they should each have a separate JVM instance. So you can still kill the specific application if you need to.
The JDK (and possibly the JRE) ship with a utility called jps which can list all Java processes but also tell you the Main-Class currently running in that JVM. If JMX/JConsole is not an option, simply parsing the output of "jps -ml" and killing the appropriate process may work.
If you want to kill an entire JVM, just kill the javaw.exe process. Within a JVM there can be multiple Java threads but there's no way to poke into a JVM and terminate a thread unless the developer of the application provided a method to do so.
Based on your comment, multiple javaw.exe programs are running and you need to know which one to kill.
You might want to try connecting to each of the processes with JConsole and inspect the JVM. There may be enough clues to determine which one to kill. Once you've identified the profile of your application, you should be able to script the logic to make it easier in the future (use JMX to get most of the information provided by JConsole).
If the executable launches javaw then exits without providing any further information it seems like you need to use your scripting language to take a snapshot of running processes on the machine before launching the executable and after the executable has finished. Then you'll be able to deduce which is the new javaw process. What scripting language are you using?
Just another approach: if you have the jdk, there is a program called jvisualVM in the bin folder. It has nice info about each running JVM context. One of the things you can see is the PID of the VM, which I use to kill the process in Windows using task manager (on windows PID is not shown by default, but you can easily enable the column by going into view -> show columns )