Hello,
I’m maintaining a legacy CF application and I’m having trouble getting certain parts of the application to work properly (or at all) when using CommandBox (but I have no issue when I run it on my locally installed CF instance).
I believe the issue may be related to older CFUI items that the application is using, but that’s only because (when using CommandBox) the server crashes when I hit pages that have lots of CFUI items in them, but if I avoid those pages the application works as intended.
I’ve run box start --debug --console and this is the error that I get whenever I navigate to one of the pages that causes a crash:
The program ‘java’ received an X Window System error.
This probably reflects a bug in the program.
The error was ‘RenderBadPicture (invalid Picture parameter)’.
(Details: serial 3662 error_code 143 request_code 139 minor_code 7)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Server’s output stream closed. It’s been stopped elsewhere.
Stopping server…
Is this a known issue? Does anyone know of a work-around?
System Info:
Linux Mint 18.2 Cinnamon
CommandBox 4.0.0+01015
cfengine: adobe@10.0.23+302580
Java version: 1.8.0_171
Thanks in advance,
-Ian
That’s certainly not a known issue. Sounds like some buginess in some Java library. Can you try that --sync parameter and see if it gives you a different/better errors. Also, check for JVM panic dump files. Not sure where they would go, possibly in the working directory the binary was ran from.
server set jvm.args=–sync
I should also add: all of the developers in our office who are on Linux Mint are also having this issue, but anyone who is on either a Windows or Mac machine are not having this issue.
Thanks for the quick reply!
I’ll try this and report back.
-Ian
Also, check out this ticket:
https://ortussolutions.atlassian.net/browse/COMMANDBOX-711
it doesn’t have a resolution, but it’s the same error and has some troubleshooting information on it.
If you add the arg “-Djava.awt.headless=true” to the jvm.args key of your server.json file, does the error still exist? It sounds like Mint may have either an incompatible version of a window server running, or none at all – but for some reason Java/CommandBox thinks it does.
That did it!
I cannot thank you enough for this. I’ve been trying to get this fixed off and on for months in my free time at work and finally broke down and decided to ask the right people for help. I guess next time I’ll ask for help sooner, haha!
Thanks,
Ian
Thanks so much for you help here Brad. This has been solved with Jon’s suggestions, but I did want to give you a bit of info from your initial suggestion:
When I tried to server set jvm.args=--sync, I got no error, but subsequent runs of start --debug --console would fail and give me:
Unrecognized option: --sync
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Server’s output stream closed. It’s been stopped elsewhere.
Stopping server…
Again, just FYI, not sure if this is info you want or need, but I figured I’d provide it anyway.
Thanks again,
Ian
Hmm, that must just mean that --sync isn’t a valid JVM arg. If that’s the case, I don’t know what the heck that error message was telling us to do. Oh, well, it probably doesn’t matter and it’s not worth the 30 black hole of Googling to try and figure out if you have a working solution 
Thanks!
~Brad
Oh, and thanks for suggesting the fix Jon. I am curious if the system tray icon still works for you when you go in headless mode. I think the Dorkbox library that handles the tray icons and menus might use some of the AWT stuff.
If it has no side effect at all, we may want to automatically add it to all servers, but if it also disables stuff that people might want, we may want to just put a note in the docs about this. I’d love to know the try source of the error and why it seems to only affect people on Linux Mint, but that rabbit hole may have no end…
Totally agree.
I’m perfectly fine with just sticking with headless=true as long as it works for the Mint guys in our office.
Can you please confirm for me if the tray icons still work when you use that flag?
The little tray popup window no longer comes up for me (which is fine) and there is no longer a tray icon at all (which again is fine).
The only other different behavior I’m seeing now is that the application auto-opens in Firefox now when it used to open in Chrome (even if Chrome is open but FF is not). Not really a big deal to me or anyone else on our team, but it might be to others. I could have some default browser set somewhere in Mint, but I’m not sure if that’s related (nor do I even know what my default is b/c I normally just open up my applications by name anyway).
Thanks,
Ian
Ok, thanks for confirming. So I definitely don’t want to turn off AWT in general. I might consider defaulting it to off for LInux Mint users if there’s a reliable way to detect just since this causing such an issue. but either way, this deserves a page in the docs that people can Google and find (hopefully).
Regarding the default browser, that is certainly related to AWT. You can see the code here that opens a browser. A very similiar version of this same code exists in Java in runwar for when servers first start.
https://github.com/Ortus-Solutions/commandbox/blob/development/src/cfml/system/util/FileSystem.cfc#L229-L266
You can see it attempts to use AWT if it’s enabled, but if not it falls back to a more brute force method that just loops through a handful of known browsers and tries to call them. I’m sure that logic could be tweaked or make more dynamic if it became an issue.l
Ah, yep, that would do it! That’s very interesting!
Thanks for all your help here (both Brad and Jon). I’m so glad I can finally use CommandBox, haha!
Have a good one,
Ian
Hey guys, I experienced this issue too on Pop!_OS (another Ubuntu based distro). What fixed it for me was to disable the tray icon for my server. So I guess the JVM args fix had the side effect of knocking out the tray icon which is the actual problem.
I’ve been considering creating a separate tray icon application that is a gui to box server list, start, stop, etc. So one tray icon to manage all your servers - good to know there are a bunch of other Linux users out there!
We’ve discussed the option of having some “master” icon for all your servers. DorkBox allows for nested menus which would work for this, but there would need to be some sort of separate process running all the time which would register and unregister servers as they came online. Possibly, but a lot of work for sure. The other problem I’ve always had the tray icons is they run directly in the server’s JVM process and don’t funnel through the CLI to stop servers so things like onServerStop interceptors never fire.
Oh yeah definitely would be a bunch of work. I would see this as an application completely separate from CommandBox. Just a GUI front-end to the command line commands. Would definitely be a mistake to build into commandbox/runwar itself I think.
For reference, here’s what I’m running on my local dev machine to make the tray icon not show by default on any local server:
box config set server.defaults={trayEnable=false} --append
HTH