View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003038 | OpenFOAM | Bug | public | 2018-08-10 01:07 | 2018-08-14 17:27 |
Reporter | TZirwes | Assigned To | henry | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | suspended | ||
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: 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 Reproduce | run 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"). | ||||
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. |
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 |