|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003038||OpenFOAM||[All Projects] Bug||public||2018-08-10 01:07||2018-08-14 17:27|
|Target Version||Fixed in Version|
|Summary||0003038: memcpy on overlapping ranges in gzstream|
|Description||I 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:
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 Reproduce||run blockMesh|
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").
|Tags||memcpy, memory access|
|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?|
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.
|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|