2018-08-19 20:26 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0003038OpenFOAM[All Projects] Bugpublic2018-08-14 17:27
ReporterTZirwes 
Assigned Tohenry 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionsuspended 
Product Version5.x 
Target VersionFixed in Version 
Summary0003038: memcpy on overlapping ranges in gzstream
DescriptionI compiled OpenFOAM 5.x (7f7d351) with Clang's address sanitizer. When I run "reactingFOAM" on the attached test case, I get the following error:

==21621==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x617000003fe0,0x617000003fe4) and [0x617000003fe3, 0x617000003fe7) overlap

The test case is the standard counterflowFlame2D_GRI tutorial case with the following modifications:
* The grid has a size of 100x100
* The file 0/H2.gz has been added
* The boundary conditions and their names have been changed in order to reproduce the bug (the bug happens during the I/O for the solver initialization, so the actual boundary conditions do not matter).

The error occurs when "0/H2.gz" is read during the start of the solver and the initialization of the multi-component mixture object. The error occurs in this function:
https://github.com/OpenFOAM/OpenFOAM-5.x/blob/master/src/OpenFOAM/db/IOstreams/gzstream/gzstream.C#L88

At some point while H2.gz is read, the parameters for memcpy in line 88 have the following values (on my machine):
buffer = 0x617000003fe0
n_putback = 4
gptr() = 0x617000003fe7

For memcpy, this means that the range between the destination and source address is:

0x617000003fe7+(4-4) - (0x617000003fe0-4) = 3

Therefore, four elements (num = 4) are copied, but there are only 3 elements separating the beginning of the source and destination ranges. Since memcpy cannot be used on overlapping ranges, Clang's address sanitizer gives an error.

I don't know if this affects the solver, but it seems to be a bug.
Steps To Reproducerun blockMesh
run reactingFoam
monitor the values of "buffer", "n_putback" and "gptr()" in gzstreambuf::underflow() during the initialization of the solver (in particular the initialization of the psiReactionThermo object and the I/O of "0/H2.gz").
Tagsmemcpy, memory access
Attached Files

-Relationships
+Relationships

-Notes

~0009944

henry (manager)

We have not seen any problems compressing and uncompressing files. If you think there really is a problem can you provide a patch to correct it?

~0009952

henry (manager)

It is not clear if there is a real issue here as there have been no problem with using compressed format in OpenFOAM for the last 10 years of using gzstream.

If there is a real issue we will need a case which demonstrates the problem and a patch to fix it.
+Notes

-Issue History
Date Modified Username Field Change
2018-08-10 01:07 TZirwes New Issue
2018-08-10 01:07 TZirwes File Added: modified_counterFlowFlame2D_GRI.tar.gz
2018-08-10 01:07 TZirwes Tag Attached: memcpy
2018-08-10 01:07 TZirwes Tag Attached: memory access
2018-08-10 07:47 henry Note Added: 0009944
2018-08-14 17:27 henry Assigned To => henry
2018-08-14 17:27 henry Status new => closed
2018-08-14 17:27 henry Resolution open => suspended
2018-08-14 17:27 henry Note Added: 0009952
+Issue History