nikhilgupta10
commented
7 years ago nikhilgupta10 imported these comments from Sourceforge: "dchassin": * status changed from new to accepted
Started work with r4025
,
"dchassin":Correcting this revealed a more subtle problem. Asserts fail during commit and commit failure handling was one of the two situations that return an error instead of throwing an exception. This means that there are 8 additional validation failures because an error is expected but an exception is received.
So, the question is are assert failures exceptions (as they are in compilers) or are they errors (as there are in GridLAB-D 2.x)? I vote exception. They should never happen and are used to identify exceptional (read outside bounds) conditions.
By the way, the seemingly spurious \EXCEPTION: synchronization failure\ is also this type of problem. It comes from a similarly failed sync event.
,
"dchassin": * owner changed from dchassin to andyfisher
- status changed from accepted to assigned
Fixed in r4027. Removed the fprintf in core/exception.c when normal exception handling was performed (no need to report that). The outer loop converts these internal exceptions to exit errors during termination processing anyway.
Also cleaned up the main exec loop test so it's easier to read and added a new exec_sync_isrunning function to allow testing of any sync event accumulator for whether it would keep a model running.
Ready for validation and merge back into trunk.
,
"andyfisher": * status changed from assigned to closed
- resolution set to fixed
Validation passed on all Windows builds as of r4031
,
This can cause a memory leak and must be immediately fixed.
,