I understood that anything to standard out (System.out) would appear in the Java Console window (when it's enabled). I spotted somewhere though that there might be situations where this isn't try, for example, from Swing apps. Is that the case?
Basically, what situations or setups wouldn't I expect to see standard output in the console? Is there a difference in behavior running on the JDK rather than explicitly on the JRE for example? javaw.exe?
ps, I understand how to display the Console in the Java settings but I'm curious as I've managed to create an application, run as an executable jar, that doesn't start the console despite some calls to System.out) on Windows 7.
The only way you wouldn't see System.out output in the console is if the method System.setOut has been invoked. This method is invoked to redirect output to the graphical Java Console, but I don't know of any other realistic circumstance in which it would be redirected away from the Java Console unless you do so voluntarily.
Depending on terminal settings it can happen that the output is not written until a newline character is sent as well. So if you do System.out.print("test") it might not appear immediately.
On Windows this is usually not the case, but on Unix terminals this is quite common.
Perhaps you use javaw to start virtual machine, this version will not show console messages. You can use java to start the virtual machine, which will show the console message.
javaw is intended for apps with windows, java is intended for console apps.
Same thing happened to me. I could not get System.out.println or Logger.debug either on console.
If you are on a huge project in Eclipse or whatever, you can read below.
Solution: I realized that I had not committed jars and some java files to SubVersioN on network. thats all. Project had not been compiled.
One situation I can think of is to invoke System.setOut(null) (orSystem.setOut(any OutputStream other than System.out or System.err)) then the console, if exists, would show nothing.
Related
I have a GUI application which contains a websocket server QWebSocketServer. I also have a python script which sends messages and the application processes them. Everything works well. During testing I wanted to run the application in headless mode using -platform offscreen command line argument added to the app executable name (I changed nothing else). But the problem is that when the application runs off-screen, the client script cannot establish connection with the web socket server. I tested this on localhost only. I do not understand how this two things, visibility of GUI and websockets, can interfere. Any ideas what could go wrong?
Note: I am using Qt 5.11.1 64-bit with VS 2017 on Windows 10 Pro.
A platform plugin is a bit more than merely "GUI". The -platform option selects a family of platform-specific plugins. Perhaps some plugins that make networking work are absent on that platform spec. That's very likely, since the offscreen platform is only a proof-of-concept: it's to show how you'd write a platform plugin. It's example code, and it does the bare minimum needed. It's nothing that you should be using for production without fully understanding what's there and how it works - it wasn't not meant for it, at least not the last time I looked at it. It shouldn't be hard to make it work, but you'd need to clone the source and start hacking on it.
Having compiled and linked a NaCl module I am now attempting to debug why it seemingly won't run. Unfortunately the platform is not passing on ANY information about why nothing is happening.
I can't believe I'm asking something this basic but what do you have to do to get a single printf() statement to appear in stdout/stderr? Or in the Javascript console?
Yes I've read the SDK page about Debugging and enabled all the dozens of environment variables and flags, I've turned the logging verbosity up to max, and absolutely none of it makes the blindest bit of difference. No information whatsoever appears anywhere.
Occasionally the JS console will print the line "ServiceRuntime::Start (start failed)" (which also appears in stdout) but it's far more often that I get nothing at all.
NaCl SDK version is 28, am running Chrome 30 on OS X Mavericks.
Command used to start Chrome with the Graphics 3D example in the SDK:
export NACL_EXE_STDERR=~/nacl_stderr.log
export NACL_EXE_STDOUT=~/nacl_stdout.log
open -a "Google Chrome" http://localhost:5103/api/graphics_3d/ --args --enable-logging --no-sandbox --vmodule=ppb*=4
This should generate a ton of logging but the log files are never created.
As discussed on the mailing list, the solution is to make sure you invoke chrome (e.g. from the command line) using the actual path to the Chrome binary (for example, "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome") instead of using the open shell command, because open does not give you the stdout/stderr streams from the application it launches.
I have a small app that I'm trying to build against windows machines. The program creates an OpenVPN connection. If I build the program and run it it first opens a console as the program output. If I pass the -w parameter to pyinstaller to not build it with a console attached the program fails to run at all. It opens allright but the vpn connection is never created.
With the console everything works perfect.
I also have a basic logging for the application in place to see where my code might stop and nothing gets written. With console on my program spits out all kinds of logs.
I just don't know why my program could be performing perfectly with a console but doing nothing without one. Any ideas?
Gonna answer this myself. Make sure you don't print anything and also you redirect all stdout to a logger, file or whatever else instead of the console.
I was having a similar problem, but couldn't find any print/stdout statements going to console. I was using subprocess.Popen and redirecting stdout=subprocess.PIPE. I subsequently added stderr=subprocess.STDOUT and stdin=subprocess.PIPE and my program worked. This page (Python subprocess.call() fails when using pythonw.exe) on subprocess failures helped me get it working.
I have an update function in my app - it downloads and verifies the installer (a setup.exe, created with NSIS). To actually kick off the update, I have simply been doing:
QString path = .. absolute path to the downloaded file ...
QProcess::startDetached(path, QStringList());
This works fine on XP - but on Vista and Win7, nothing happens once the download completes. If I browse to the downloaded update and run it manually, it works fine. I assume what's happening is that UAC is blocking the installer at CreateProcess time, but this is where my knowledge runs out.
Additional complication - when I'm running a debug build from the command line, the steps above work - I get the UAC prompt and can run the installer. It's the release builds, started form the start menu/shortcut, which have the issue - I assume there's a difference in the auth token when running from a command shell.
You can also use
QDesktopServices::openUrl(QUrl::fromLocalFile(path));
Might be surprising and counterintuitive, but it works and is more cross-platform
If you are not admin and you call CreateProcess() on a .exe with a "Vista" manifest (or no manifest, but a .exe that windows detects as an installer (This includes NSIS)) the call fails, you need to use ShellExecute[Ex](). ShellExecute will trigger UAC prompt if required...
This seems to be a Qt bug, see QTBUG-9761 , the correct workaround is to use ShellExecute with lpOperation set to runas.
Another alternative is to prepend your execution with cmd.exe /C. This effectively routes your execution through the shell, so you do get the UAC prompt. The downside is that if your process fails you probably won't get as much information had you gone through ShellExecute[Ex], but on the plus side you will get all the facilities of QProcess that you miss if you use QDesktopServices::openUrl, where you have no idea if things worked or not.
I've written a c# windows app, that performs some DB intensive operations. (MySQL connector v6).
When running the project in Debug mode, everything works fine. However, when I run the prject in release mode, it sometimes quits operation midway - with no error message, nothing in the event logs etc.
What would be the best way to debug release mode - when everything works in debug mode?
Thanks for any help,
Bob
You can create a log file and have the application write lines to it with information of your choice, similarly to how the console may be used for debug purposes in a windows form application. You can write values of certain variables to this file, or even just write distinct phrases in select places of the code that will help you detect where the program is in execution when it fails.
Bobby is correct in asking about Application Event Log. If it is bombing on a .NET error, it will likely be logged.
If that doesn't give you anything, wrap the entire app in a try/catch block. On your exception handling, log the error (application log, file, etc...). Make sure when you log it to capture the call stack.
I've got exactly the same problem - application running in debug mode and fail in release. Try the following:
Wrap everything in Program.cs in try{}..catch{} block and it will show a reason
I don't know why but my application failed on Program.SetCompatibleTextRenderingDefault() function with message that it should be called before any instances on IWin32Window or something like that
It is very strange errors for me cuz i didn't have any code before this function. But you can try - maybe it will show something useful for you