buggy re-initialization of RFortran / broken logic in messageLog

[GoogleCodeExporter]

*** What steps will reproduce the problem?

1. Put a loop around the code in (for example) TEST_Rplot_3D to simulate
multiple opening/closure of RFortran

2. Run the code

*** What is the expected output?

RFortran opening/closing and operating correctly

*** What do you see instead?

A memory access issue (debug assertion failure) on line 464 of
MUtilsLib_messageLog.f90. The bug is triggered depending on running
context, eg, stepping thru versus just running debugger, etc.

Representative of memory corruption often encountered when using
allocatable arrays...

*** What version of RFortran are you using?

2.0.2

*** What Fortran compiler (name and version number) are you using?

CVF6.6.B2

*** Please provide any additional information below.

The immediate problem occurs due to the use of allocatable arrays inside
derived types. This is non-standard Fortran-95 and is not implemented
correctly in CVF (especially when expecting that deallocating the derived
type will automatically deallocate all internal components of this type!).
Instead, a pointer should be used to ensure F-95 conformance, and more care
paid to deallocating internal structures.

However, the very logic of "init_msg_db" appears broken - it is creating a
separate log/database everytime Rinit is called. Is this really intended?

Original issue reported on code.google.com by dmitri.k...@gmail.com on 15 Apr 2010 at 9:11

[GoogleCodeExporter]

Issue 66 has been merged into this issue.

Original comment by mark.th...@gmail.com on 16 Apr 2010 at 5:20

[GoogleCodeExporter]

In r527 , r528  and r529 I have addressed the issue of init_msg_db creating a 
new log every time Rinit is called, 
see svn:log for details

RE: Use of allocatable arrays in derived types

The current implementation has no problems in IVF11.0. Testing reveals that the 
deallocating the derived type does 
actually deallocate internal allocatable components.   
Since my CVF is not operational, it is difficult for me to diagnose this 
problem and I request that you make the 
necessary changes to make it CVF-compatible and supply a patch for me to 
implement, hence I am changing the owner of 
this issue to you.  

I have also added a new TEST_Rinit_multiple to test reinitialisation problems.

I have extended this example to illustrate how I recommend you handle multiple 
RFortran initialisation's in 
BATEA/DMSL. Call init_log first with always_append=.true. and then all messages 
get written to the same log file, 
otherwise the message.log will be overwritten everytime Rinit is called. 

Original comment by mark.th...@gmail.com on 16 Apr 2010 at 5:50

• Changed state: Started

[GoogleCodeExporter]

Mark, I repeated the RFortran tests, both with the 'samples' and with BATEA.

Your modifications have avoided triggering the multiple-Rinit bug in CVF, which 
is a
good thing for the immediate future.

However, I checked the code and this occurs not by removing the potential 
trigger
(the non-F95 allocatable components and a seeming CVF bug in their automatic
deallocation) but by improving the logic of the logging routines resulting in 
the
problematic branch no longer being executed in the current BATEA case (which is 
a
good thing here, but does not actually address the potential bug/trigger).

To enable me to debug this properly, can you design a test program that would 
enter
the branch "if(allocated(msg_db))" on line 460 of MUtils_messageLog.f90. I am 
unsure
what these circumstances are (or should be?), but once that is done I will 
easily
check that my (likely) solutions works correctly.

I have hence reverted to the rightful owner of this issue ;-) but downgraded the
priority from blocker to critical

Original comment by dmitri.k...@gmail.com on 16 Apr 2010 at 12:15

• Added labels: Priority-critical
• Removed labels: Priority-blocker