SLADE
SLADE copied to clipboard
sirjuddington
ZenNode hangs SLADE on linux/macos
SLADE Version: (3.1.2.alpha) SLADE Version: (3.1.0.4)
Operating System: (Linux) Debian and Slackware
Issue Details: Clicking "Run Archive," setting node builder and port will hang Slade forever. The nodebuilder appears to start but never actually builds nodes. Slade has circlespinning mouse cursor, so it does not appear frozen, just unresponsive. Slade process needs to be killed.
This has been happening for 2 years at least. My old system was Slackware 14.1 and is now Debian 8.7, with entirely different window managers and (probably) versions of libs. Slade behaves identically.
Identical behavior on vastly different systems: http://www.geocities.ws/catodemos/screenshots/slade2.png http://www.geocities.ws/catodemos/screenshots/Screenshot%20-%2008142015%20-%2010:39:07%20PM.png
Old bug report for same issue: http://mancubus.net/forums/index.php/topic,3321.0.html
"Run Archive" never works because nodes will never build.
Hmm no idea why this is happening, is it to do with ZenNode maybe? Does it happen if you use GLBSP or ZDBSP?
Zdbsp and glbsp build fine from within Slade. I noticed zennode actually displays "Zennode version with date" in the terminal of Slade when attemping to build nodes. Both, zdbsp and glbsp display nothing on the terminal while building.
When it happens, do you have an active zennode process? What happens if you kill it instead of killing SLADE?
Does Zennode have an "interactive" mode where the user must input commands? Because it seems like Zennode is waiting for something that never comes, and SLADE is waiting for Zennode to finish.
There should still be a timeout when calling external applications to make sure that Slade doesn't lock up like this.
New Example: Have Slade build nodes with Zennode, run $ps -e, kill id of Zennode. Slade starts to work normally again. Did this three times, Slade still works fine as long as Zennode is manually killed.
What it looks like. http://www.geocities.ws/catodemos/screenshots/slade3.png
Remember zdbsp and glbsp actually build nodes, but have no terminal output at all, might be a clue.
Try setting log_verbosity to 5 in the console then build nodes, it should log the command that is being executed to run zennode. Try running that command in a terminal and see if zennode is doing something it shouldn't.
Quotes seem off. http://www.geocities.ws/catodemos/screenshots/slade4.png
This is exact terminal output while messing around. http://pastebin.com/1Hwvf8BF First tried exact command from Slade's internal console...execute not found. Then same command with no quotes....built nodes.
Slade seems to be acting like there is an extra quote.
There's no extra quote. Look more closely:
execute "/home/cato/.chocolate-doom/ZenNode "/home/cato/.slade3/tmp/sladetemp.wad" -o "/home/cato/.slade3/tmp/sladetemp.wad""
If I replace quotes by numbered braces to make it clearer: execute {1 program {2 tempwad 2} -o {3 tempwad 3} 1}
Try this on the command line: /home/cato/.chocolate-doom/ZenNode "/home/cato/.slade3/tmp/sladetemp.wad" -o "/home/cato/.slade3/tmp/sladetemp.wad"
Because I'm not seeing mismatched quotes here (there would be an odd number of \" if there was) so from your pastebin I'm left to conclude that ZenNode doesn't seem to be able to handle quote marks around the filenames.
These quote marks are needed for when a path contains a space, however.
I don't know if this has anything to do with this bug, but if ZenNode is not given an output filename, it will write the output WAD to its working directory instead of replacing the WAD file it was given.
I can reproduce this on macOS. The command works if copy-pasted just fine. This is on the latest stable release.
Everything listed here is the exact same—no differences regarding the bug.
I'll likely go ahead and do some debugging to see what's hanging.
Update: I suspect this is an issue with ZenNode. It looks like it does some weird stuff, and expects the command to be run at a TTY. I'm not totally familiar with whatever it's trying to do, but the general path of execution does involve changing the terminal's settings as well as listening for keyboard input.
wxExecute is certainly hanging, but it does fine with other commands and even printing the help text for ZenNode itself.
For this one I might just look at adding zennode as an internal nodebuilder since it's open source (GPL) and from what I can tell hasn't been updated since 2004
Right at the entry point I spotted the issue..
while ( KeyPressed ()) GetKey (); right after printing the Zennode banner. (line 940 ZenMain.cpp)
also at
if ( KeyPressed () && ( GetKey () == 0x1B )) break; line 973
I commented both lines and ZenNode didn't hang up anymore.
I can't figure for what reason ZenNode checked Key presses before resuming...
