trying to open GUI Designer .form file crashes IntelliJ

Please provide `hs_err_pid*.log` files in IDEA_HOME\bin.

If you don't see them, add `-XX:ErrorFile=C:/temp/java_error_%p.log` into .vmoptions (https://intellij-support.jetbrains.com/hc/articles/206544869). Make sure the specified folder has write permissions. Attach the log files after the crash.

Serge, thanks for your response.

I first note that I am running IntelliJ under the latest 64-bit JVM, as proved by this screen shot of the IntelliJ About dialog:

So, following the instructions in you support link, I added a line

-XX:ErrorFile=C:/Temp/java_error_%p.log

to my ...\IntelliJ IDEA Community Edition 2016.1.x\bin\idea64.exe.vmoptions file.

Opening the GUI's .form file still immediately crashes IntelliJ, however, no java_error_... file is written to that Temp directory.

I tried adding that line to my idea.exe.vmoptions file as well, just to be sure, still no error file written.

I tried simplifying the line to

-XX:ErrorFile=C:/Temp/java_error.log

(as maybe the %p is problematic) and that still fails to produce a error file.

Finally, to prove that IntelliJ has write permissions to that directory, I added this line to my project's main method:

Files.write( Paths.get("C:/Temp/fakeError.txt"), "hello world".getBytes() );
It worked perfectly, writing the text file as expected.

So, I am at a total loss as to why IntelliJ is crashing and why it crashes so bad that it seemingly does not even write that JVM error file.

As stated in the document, editing .vmoptions file inside the bin folder is not recommended. If you edit is as non-admin user, the settings will not be visible to IDE. Please use IDE menu to edit .vmoptions instead. Also share your logs folder. idea.log will have the list of actual .vmoptions so that you can verify that this setting was applied.

OK, I read your support link more carefully, and this time I followed its recommendation to open the the Help | Edit Custom VM Options menu.  The file that popped up already had the line

-XX:ErrorFile=C:/Temp/java_error_%p.log

at the end (as expected: your link says that IntelliJ should make a copy from the master version that I already manually edited).

I then tried to open the GUI .form file, and IntelliJ again immediately crashed, still no error file written.

The idea.log file, however is most interesting, thanks for pointing it out.  I have attached it.  There are 2 exceptions that seem to be related to indexing.  Given that they are logged at INFO level, I assume that they are more or less harmless.

But the 3rd Exception which starts with this

2016-06-10 12:15:33,335 [  52301]  FATAL - ral.equitycontrolgui.GetConfig - GetConfig.staticInitializer: caught an unexpected Throwable (see cause) while loading the config file 
java.io.FileNotFoundException: config\main.properties (The system cannot find the path specified)
    at java.io.FileInputStream.open0(Native Method)

is most interesting.  Evidently, loading the GUI .form file is triggering the class load of GetConfig, which is a custom class in this project.  A change has been made (probably by me) which causes it to not find an expected property file, so that class load fails.  This is a bug for me to fix.

That said, I think that IntelliJ has bad error handling.  A bug like this in my code should not cause IntelliJ to crash as well. 

Instead, IntelliJ should have displayed that final stacktrace to me and remained running.

Update: Serge, if you want a copy of my idea.log file, how can I deliver it to you?  I tried to do a file attachment using the picture icon, but it only allows graphics file to be uploaded.  I see no other options in the new very barebones forum options.

Maybe your custom class just calls System.exit()? That would explain why there is no crash log.

Serge, yes, the custom class does call System.exit in this case.

That said, do you agree that application code which calls System.exit should not exit IntelliJ itself?

When you run normal applications, this does not happen of course.  There must be something different in how IntelliJ loads a GUI .form file that a call to System.exit in a referenced class causes IntelliJ itself to die.

Serge: I was shocked to learn that double clicking on my project's .form file, which opens it in GUI Designer, would cause the side effect of loading other classes (e.g. the problematic custom GetConfig class you already know about).  I did not think it would do that.

I think that what is happening is that the .form file refers to named JButton fields that are defined in another class of this project, and those JButton fields have ActionListeners that ultimately cause classes like GetConfig to be loaded.

In particular, besides GetConfig, another class that gets loaded if you open the .form file is the DatabaseManager class.  The default config directory for this project is wired to tap into our prd database.  That raises the possibility that someone could double click on the .form file and then load code that could potentially modify our prd database.  Holy crap!

So, Serge, is there any documentation that you could point me to which discusses side effects of working with .form files in IntelliJ, best practices, etc?

Form class has to be instantiated by IDE so that it provides GUI designer features for the form. As there is no way to specify additional environment like working directory, it could happen that the loaded code fails in some way,

Calling System.exit() is really a poor practice and there is nothing IDEA can do to prevent that.

You have to redesign your form so that it doesn't depend on some file location in the system or so that it handles the case when it's loaded from the UI designer and not from the production app.