+ update 2020: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means we will NOT develop new features and/or fix most of bugs. We left the tracker running in case somebody from community would like to work on it. Sorry for the inconvenience.
State: closed new: Initial state. As long as issue is in this state, the work on the issue has not yet begun. opened: Opened state means developer started working on the issue. Feature/Fix will probably be in the next release. postponed: This means developer is not working on it now, for some reason it cannot be implemented now. Issue may be opened again in the future. upgraded: Issue is in upgraded state when developer made changes to the program and new version was released. closed: This means the user is satisfied with issue results and no more changes are needed. invalid: These issues cannot be solved. ignored: Developer decided to take no action on this issue. returned: Program changes were made but user is not satisfied and returned the issue.
> What steps will reproduce the problem?
Use the commandline interface of FFDec on a GUI-less OS / SSH session (to a server for
> What is the expected output? What do you see instead?
The commandline interface should work, whether the OS / current SSH session has a GUI or
Currently, the logger raises an exception, as it seems to rely on the GUI, and FFDec get
stuck without doing anything.
The exception shown is:
Exception in thread "main" java.lang.RuntimeException: Problems with creating the log
> What version of the product are you using? On what operating system?
I use recent versions, I guess the logging system was introduces few weeks/monthes ago. I
use FFDec on a Ubuntu 12.04 server (that I get connected to through SSH).
> Please provide any additional information below. Attach the file you have problem with
if neccessary. If you do not want to publish files YOU CAN CHANGE VISIBILITY TO PRIVATE
It works fine if we can enable X11 forwarding through SSH (so doesn't work for Windows
OSes hosts, at least out of the box).
I tried to track down the Exception, it comes from the "clearLogFile();" call in the
initLogging method (of com.jpexs.decompiler.flash.gui.Main.java), which calls
"ErrorLogFrame.getInstance().clearErrorState();". "ErrorLogFrame.getInstance()" will try
to instantiate a new com.jpexs.decompiler.flash.gui.ErrorLogFrame object, which will raise
the exception as it relies on GUI components.
I didn't expect an answer so quickly, thanks!
Unfortunately, it isn't completely fixed in the latest nightly build, I get another
Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires