View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004003 | OpenFOAM | Bug | public | 2023-08-03 09:25 | 2023-08-09 11:12 |
| Reporter | petteri | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 15.04 |
| Product Version | dev | ||||
| Summary | 0004003: Undefined behaviour in LUDecompose | ||||
| Description | In scalarMatrices.C line 85: label m = matrix.m(); scalar vv[m]; where vv should be an array of length m. The row count of the input matrix is, in general, not known compile time making the array creation UB. Modern compilers however seem to be doing the right thing here as 'LUDecompose' is called all over the place. | ||||
| Steps To Reproduce | Call Foam::LUDecompose( scalarSquareMatrix&, labelList&) | ||||
| Tags | No tags attached. | ||||
|
|
> Modern compilers however seem to be doing the right thing here Yes this is defined functionality in modern C and C++, or do you have evidence to suggest otherwise? Can you provide a case which fails? |
|
|
I assume that if the compilers are not able to deduce the array size at compile time they will reserve some relatively large buffer for the array. To trigger issues, the matrix (and the array) would have to be relatively large. Here's a demonstration: https://godbolt.org/z/xn7G66efz |
|
|
According to the current C standard scalar vv[m]; is valid and I don't recall any particular limit specified for m. Maybe there is a bug in the compiler you are using. We don't have any OpenFOAM examples for which the current implementation fails. |
|
|
It appears that the C99 standard added support for variable length arrays (VLA) but they were again removed in C11, however, some compilers still provide the support for it. The C++ standard has never supported VLAs but some vendors are kind enough to support old C features. That being said, the maximum limit of the created buffer is totally up to the compiler vendor and likely depends on the system you are running on. I am not exactly sure where the LUDecompose function is called and what is a typical size for the input matrix. The ODE solvers make calls to LUDecompose but typically the chemistry ODE system is quite small. Therefore, I'm not sure if trusting UB in this case is a problem in practice but issues may appear in the future if the compiler vendors decide to treat VLAs in C++ somehow different. |
|
|
I am not able to reproduce the problem with any OpenFOAM cases we have or with any C++ compiler we have. If you are having particular difficulties with very LU decomposition of very large matrices I suggest you use a more appropriate LU decomposer for your cases. |
|
|
User support |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-08-03 09:25 | petteri | New Issue | |
| 2023-08-03 09:59 | henry | Note Added: 0013087 | |
| 2023-08-03 10:21 | petteri | Note Added: 0013088 | |
| 2023-08-03 12:44 | henry | Note Added: 0013089 | |
| 2023-08-03 13:26 | petteri | Note Added: 0013091 | |
| 2023-08-03 13:54 | henry | Note Added: 0013092 | |
| 2023-08-03 13:54 | henry | Assigned To | => henry |
| 2023-08-03 13:54 | henry | Status | new => closed |
| 2023-08-03 13:54 | henry | Resolution | open => no change required |
| 2023-08-03 13:54 | henry | Note Added: 0013093 |
