View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003856 | OpenFOAM | Bug | public | 2022-07-05 18:47 | 2022-07-16 22:51 |
| Reporter | Tiberias_ | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Fedora | OS Version | 36 |
| Product Version | dev | ||||
| Summary | 0003856: #calcEntry in blockMeshDict produces IO Error with GCC 12 | ||||
| Description | When building OpenFOAM dev, 9 or 8 with gcc 12.1 blockMesh gives following error: Create time Reading "blockMeshDict" Creating block mesh from "system/blockMeshDict" Using #calcEntry at line 34 in file "/home/user/documents/workDir/3_fine_t/system/blockMeshDict" --> FOAM FATAL IO ERROR: error in IOstream "OSHA1stream.sinkFile_" for operation Ostream& operator<<(Ostream&, const string&) file: OSHA1stream.sinkFile_ at line 0. From function virtual bool Foam::IOstream::check(const char*) const in file db/IOstreams/IOstreams/IOstream.C at line 96. FOAM exiting calc entries looks like lx #calc "$xmax - $xmin"; ly #calc "$ymax - $ymin"; lz #calc "$zmax - $zmin"; xcells #calc "abs($lx / $dx)"; ycells #calc "abs($ly / $dy)"; zcells #calc "abs($lz / $dz)"; When building with gcc 11.2 at RHEL blockMesh works without problems. | ||||
| Steps To Reproduce | build OpenFOAM dev with GCC 12.1 run any blockMesh case with calc entries | ||||
| Tags | No tags attached. | ||||
|
|
There appears to be bugs in the optimiser in gcc-12.1, if you compile with -O0 it will run fine. I am currently using gcc-10.1 without any problems. |
|
|
I just compiled OF-dev with disabled optimising and for some reason the above error appears again. Just to make sure I did the right things, I changed the -O3 parameter in OpenFOAM-dev/wmake/rules/linux64Gcc/ to -O0. The parameter was also present during the compilation process. |
|
|
Yes this is the correct change, you would need to recompile the main OpenFOAM library. I have investigated the problem further and traced it to the sha1streambuf::xsputn function. According to the C++-11 standard this function may call an overload function (which is not currently provided): https://cplusplus.com/reference/streambuf/streambuf/xsputn/ Its default behavior in streambuf is to retrieve n characters, as if calling sputc for each, stopping if any call would return EOF. Except it is unspecified whether member overflow is called or whether other means are used in case of overflows. https://cplusplus.com/reference/streambuf/streambuf/overflow/ int overflow (int c = EOF); Put character on overflow Virtual function called by other member functions to put a character into the controlled output sequence without changing the current position. It is called by public member functions such as sputc to write a character when there are no writing positions available at the put pointer (pptr). Its default behavior in streambuf is to always return EOF (indicating failure), but derived classes can override this behavior to attempt to write the character directly and/or to alter pptr and other internal pointers so that more storage is provided, potentially writing unwritten characters to the controlled output sequence. Both filebuf and stringbuf override this virtual member function. Parameters c Character to be put. If this is the end-of-file value (EOF), no character is put, but the other effects of calling this function are attempted. Return Value In case of success, the character put is returned, converted to a value of type int_type using member traits_type::to_int_type. Otherwise, it returns the end-of-file value (EOF) either if called with this value as argument c or to signal a failure (some implementations may throw an exception instead). It looks like the gcc-12.1 implementation requires the overflow function whereas previous implementations didn't. I will work on this today. |
|
|
I implemented a dummy sha1streambuf::overflow(int c = EOF) which just prints a message and it is indeed called when compiled with gcc-12.1 but not with gcc-10.1. I will now implement the body of this function according to the C++11 specification and test. |
|
|
Try this: commit 0aabdbf4a796d7e1d3d53e9ce2db5fda2b8f5003 Author: Henry Weller <http://cfd.direct> Date: Wed Jul 6 16:58:44 2022 +0100 OSHA1stream: Updated to C++11 According to the C++11 standard the xsputn might call an overload function which must be provided for correct operation and is required by gcc-12.1 but not earlier releases. See https://cplusplus.com/reference/streambuf/streambuf/xsputn/ Its default behavior in streambuf is to retrieve n characters, as if calling sputc for each, stopping if any call would return EOF. Except it is unspecified whether member overflow is called or whether other means are used in case of overflows. https://cplusplus.com/reference/streambuf/streambuf/overflow/ int overflow (int c = EOF); Put character on overflow Virtual function called by other member functions to put a character into the controlled output sequence without changing the current position. It is called by public member functions such as sputc to write a character when there are no writing positions available at the put pointer (pptr). Its default behavior in streambuf is to always return EOF (indicating failure), but derived classes can override this behavior to attempt to write the character directly and/or to alter pptr and other internal pointers so that more storage is provided, potentially writing unwritten characters to the controlled output sequence. Both filebuf and stringbuf override this virtual member function. Parameters c Character to be put. If this is the end-of-file value (EOF), no character is put, but the other effects of calling this function are attempted. Return Value In case of success, the character put is returned, converted to a value of type int_type using member traits_type::to_int_type. Otherwise, it returns the end-of-file value (EOF) either if called with this value as argument c or to signal a failure (some implementations may throw an exception instead). Resolves bug-report https://bugs.openfoam.org/view.php?id=3856 |
|
|
Works without problems now, blockMesh compiles dynamicCode as expected. Thanks for the fast response on that issue! |
|
|
Resolved in OpenFOAM-9 by commit b0c15bebd37142f3902901ed5e9a60e33ed456eb Resolved in OpenFOAM-dev by commit 0aabdbf4a796d7e1d3d53e9ce2db5fda2b8f5003 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-07-05 18:47 | Tiberias_ | New Issue | |
| 2022-07-05 22:07 | henry | Severity | block => minor |
| 2022-07-05 22:08 | henry | Note Added: 0012658 | |
| 2022-07-06 00:28 | Tiberias_ | Note Added: 0012659 | |
| 2022-07-06 07:46 | henry | Note Added: 0012660 | |
| 2022-07-06 09:31 | henry | Note Added: 0012661 | |
| 2022-07-06 17:04 | henry | Note Added: 0012662 | |
| 2022-07-06 22:22 | Tiberias_ | Note Added: 0012663 | |
| 2022-07-06 22:42 | henry | Assigned To | => henry |
| 2022-07-06 22:42 | henry | Status | new => resolved |
| 2022-07-06 22:42 | henry | Resolution | open => fixed |
| 2022-07-06 22:42 | henry | Fixed in Version | => 9 |
| 2022-07-06 22:42 | henry | Note Added: 0012664 |
