#853 Output on linux autotest differs from windows,

[nikhilgupta10]

The output of the new autotest (see ticket:114) differs on Linux and windows. On windows there is a full sequence of random numbers. On Linux the output is empty.

Note: this appears to be unrelated to ticket:114 byt the cause is not known at this time.,

[nikhilgupta10]

nikhilgupta10 imported these comments from Sourceforge: The user laurmarinovici does not exist anymore. Therefore assigning this to afisher1. "jcfuller":- status: unassigned --> assigned

• assigned_to: Andy Fisher ,

  "jcfuller":- assigned_to: Andy Fisher --> Laurentiu Marinovici ,

  "andyfisher":What autotest?,

  "laurmarinovici":I think it refers to test_c_include.glm Will look at it momentarily.,

  "laurmarinovici":- assigned_to: Laurentiu Marinovici --> David P. Chassin ,

  "laurmarinovici":It looks like #include<*.h> is not handled correctly. I get no output file at all in both Windows and Linux, when #include is on in test_c_include.glm in trunk. It seems that gridlabd exits right when it reaches that line. If I comment it out, then the output file is produced.,

  "dchassin":- status: assigned --> accepted ,

  "dchassin":I'm puzzled by something. The test for this does not even exist in 3.1. Is this test missing for a reason?,

  "dchassin":By the way, commenting out the #include defeats the point of the test. Having an include that gets into the .cpp file is essential to the test.,

  "laurmarinovici":I am as puzzled as you are, Dave. And then some, given I am a junior in GridLAB-D development. And I do agree that commenting out the #include defeats the purpose of the test. I took out to see if that is the cause of the test not going through. Which proved to be true.,

  "dchassin":Confirm this also happens on Mac OSX Mavericks. The output with verbose and debug is quite mysterious:

david:test_c_include david$ gridlabd --verbose --debug test_c_include.glm 
   ... file '/usr/local/share/gridlabd/gridlabd.conf' is 1451 bytes long
   ... include_file(char *incname='mingw.conf', char *buffer=0x0x7fff5f432f6e, int size=10226): search of GLPATH='/usr/local/lib/gridlabd:/usr/local/share/gridlabd' result is '/usr/local/share/gridlabd/mingw.conf'
   ... mingw.conf(30): included file is 574 bytes long
   ... include_file(char *incname='gnuplot.conf', char *buffer=0x0x7fff5f432f70, int size=10224): search of GLPATH='/usr/local/lib/gridlabd:/usr/local/share/gridlabd' result is '/usr/local/share/gridlabd/gnuplot.conf'
   ... gnuplot.conf(34): included file is 228 bytes long
   ... 0 object loaded
   ... file 'test_c_include.glm' is 942 bytes long
   ... added C include for \, value
   ... 0 object loaded
   ... model TRL is PROVEN
   ... load time: 0 sec
   ... starting up batch environment
DEBUG [INIT] : exec_mls_create()
   ... initializing objects...
DEBUG [INIT] : link_initall(): link startup in progress...
DEBUG [INIT] : link_initall(): link startup done ok
   ... creating index 0
   ... creating index 1
   ... creating index 2
   ... shuffled -10 lists in index 0
   ... shuffled -10 lists in index 1
   ... shuffled -10 lists in index 2
DEBUG [INIT] : nObjRankList=0 
   ... shutdown complete
   ... elapsed runtime 0 seconds
   ... exit code 0
~~~~~,

 "dchassin":On Fedora 14 (yeah, I know...), the output is even more puzzling:

[david@imacfc14 test_c_include]$ gridlabd --verbose --debug test_c_include.glm ... file '/usr/local/share/gridlabd/gridlabd.conf' is 1502 bytes long ... include_file(char incname='mingw.conf', char buffer=0x0x7fffd47b81de, int size=10226): search of GLPATH='/usr/local/lib/gridlabd:/usr/local/share/gridlabd' result is '/usr/local/share/gridlabd/mingw.conf' ... mingw.conf(30): included file is 622 bytes long ... include_file(char incname='gnuplot.conf', char buffer=0x0x7fffd47b81e0, int size=10224): search of GLPATH='/usr/local/lib/gridlabd:/usr/local/share/gridlabd' result is '/usr/local/share/gridlabd/gnuplot.conf' ... gnuplot.conf(34): included file is 278 bytes long ... 0 object loaded ... file 'test_c_include.glm' is 942 bytes long ... added C include for (null)\, value ... 0 object loaded ... model TRL is PROVEN ... load time: 0 sec ... starting up batch environment DEBUG [INIT] : exec_mls_create() ... initializing objects... DEBUG [INIT] : link_initall(): link startup in progress... DEBUG [INIT] : link_initall(): link startup done ok ... creating index 0 ... creating index 1 ... creating index 2 ... shuffled -10 lists in index 0 ... shuffled -10 lists in index 1 ... shuffled -10 lists in index 2 DEBUG [INIT] : nObjRankList=0 ... shutdown complete ... elapsed runtime 0 seconds ... exit code 0

The string is \(null)\ which can only happen two ways. 1) the pointer is null, which is impossible because value is array. 2) value contains the string \(null)\.  Since sscanf returned 1 so sscanf must have put \(null)\ in there.  Hmmm...,

 "dchassin":Ok. The mysterious output is a misplaced quote on line 5928 of load.c.  The sscanf works ok when the quote is moved. But the real problem remains.  ,

 "dchassin":So far as I can tell the presence of the #include <___.h> causes the loader to abort quietly in both linux and mac.,

 "dchassin":Found the problem: in process_macro, clearing a line using strcpy(line,\) causes the parser to quit.  We're supposed to clear lines with strcpy(line,\
\).  Don't ask.,

 "dchassin":Fixed in r4811. Validated ok on mac and linux.  Need to validate on windows still.,

 "dchassin":- **status**: accepted --> assigned
- **assigned_to**: David P. Chassin --> Laurentiu Marinovici
- **Resolution**: none --> validate
,

 "dchassin":Fixed for 3.1 in r4812. Need validating on linux and windows.,

 "laurmarinovici":- **status**: assigned --> accepted
,

 "laurmarinovici":- **status**: accepted --> closed
,

 "laurmarinovici":Validated. Works fine in Win32/64 and Linux32/64. Output CSV files are populated. Closing ticket #861.,

 "laurmarinovici":I meant ''closing ticket #853''. Sorry.,