Issue897

Title FDDNM: Sigsegv on at least three dialogs
Priority bug Status open
Assigned To digifuzzy Keywords
Linked issues Watchers digifuzzy

Submitted on 2017-09-03 18h18 by jesusalva, last changed by digifuzzy.

Files
File name Uploaded Type Edit Remove
Chandra.png digifuzzy, 2017-09-03.19:43:55 image/png
Messages
Author: jesusalva Date: 2017-09-03   18h18
Hello

I recently installed FreeDroid Dialog Node Mapper and it crashed when I tried to
render some files to PNG:

* Chandra
* Spencer
* TutorialTom

I also tried to render Chandra on dot format but it also crashed.
Console output: “Segmentation Fault (core dumped)”
Author: digifuzzy Date: 2017-09-03   18h32
FDDNM "MUST" be built locally.
Please see: http://www.freedroid.org/doxygen/tools/fddnm.html
in FD doxygen page for instructions to build.

Note dialog node actions/behaviour has been made more complex with Dev's writing
more involved code for user actions. This makes a rendering tool such as FDNNM
difficult to maintain.

I will verify fault and if possible offer a fix, but no promises.
Author: digifuzzy Date: 2017-09-03   19h52
Observations so far...
Changes:
2016Apr19 - Fluzz made minor change to accommodate data directory changes.
2015Apr03 - Me - bug fix to regex and add other flags to command line
2015Mar04 - Me - initial release

Errors/Discrepancies:
Doxygen page - link to diagrams broken
Building - observations
- first execution of autogen_fddnm.sh produces numerous warnings about
overwriting m4 files (ax_boost_{base,filesystem,program_options,system}.m4,
ax_cxx_compile_stdcxx_11.m4)
- autogen fails at ax_require_defined.m4 with "too many loops" errors
- second execution produces successful configuration.

Execution:
Chandra works (attached using fddnm -Tpng -G -H Chandra).
Output of Chandra attached.

Spencer and TutorialTom results in segmentation fault.
Tested fddnm with both gcc and clang
Author: digifuzzy Date: 2017-09-03   21h22
Made several attempts executing Spencer.lua dialog file.
With fddnm built with heightened debug mode, I was able to parse Spencer.
However, it was apparent that nodes were missing. Another debugging method
employed was to use Lua comment block markers to isolate which node(s) were
problematic(fddnm would fail with a segmentation fault).

General problem...
Dialog nodes with involved if/elseif/else structures or compound if clauses will
cause the fddnm to fail.
fddnm is structured using regular expressions to find "consistent patterns" in
the dialog files and go from there.
As dialog complexity has increased, defining a regex pattern for every
conceivable use case in the dialog files is not supportable.

Parsing dialog code and produce a graphical output was a "nice idea". However,
without resorting to something like boost::spirit or bison/yacc, I do not feel
fddnm will be able to handle all use cases going forward.

Recommend removal of fddnm from source tree.
RB to follow.
Author: jesusalva Date: 2017-09-06   22h41
Yes, I had similar problems in past with compound if clauses...

Maybe you're right and fddnm is not up anymore to the whole task, however, I do
not think it is necessary to remove from source tree, if you can prevent the
segmentation fault (probably using try:except statements) and skip such files
printing to console “file x cannot be rendered.”

After all, fddnm have its uses. Specially testing new dialog submissions...
Author: digifuzzy Date: 2017-09-06   22h49
If you edit Spencer dialog and use lua block comments taking out everything
after about node 52, FDDNM works fine. I did quite a bit of this block
commenting to narrow down problematic nodes.

What doesn't help are line like:
    hide("nodeX") show("nodeY")

I don't think the lua interpreter appreciates those two commands on the same
line and the behaviour IMO is undefined. Probably the hide command gets executed
but the show command -- maybe.

FDDNM was never meant to be a syntax checker for lua. If the code is bad, FDDNM
will fail - period. The segmentation fault is not always because of it's code.
Sure the error handling could be better, but I still make no promises in parsing
bad code.
History
Date User Action Args
2017-09-06 22:49:33digifuzzysetmessages: + msg3487
2017-09-06 22:41:24jesusalvasetmessages: + msg3486
2017-09-03 21:22:47digifuzzysetmessages: + msg3482
2017-09-03 19:52:23digifuzzysetmessages: + msg3481
2017-09-03 19:43:55digifuzzysetfiles: + Chandra.png
2017-09-03 18:32:39digifuzzysetmessages: + msg3480
2017-09-03 18:18:00jesusalvacreate