Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Flang] flang-new-20 Segmentation fault with open(,status=old) of non existing file when setting MALLOC_PERTURB #111404

Closed
edoapra opened this issue Oct 7, 2024 · 2 comments · Fixed by #111454
Assignees
Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] flang:runtime

Comments

@edoapra
Copy link

edoapra commented Oct 7, 2024

When compiling the code below with the current flang-new-20 and executing with MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) and with the file to be opened being not available, the code stops with a segmentation fault.
flang-new-18 and flang-new-19 are not affected by this issue.
Code

      program test
      implicit none
      logical status
      open(unit=10,file='./nwchemrc',
     +     status='old',err=9999)
      write(6,*) ' open ok'
      stop
 9999 continue
      write(6,*) ' open failed'
      end

gdb stack

Program received signal SIGSEGV, Segmentation fault.
0x000055555557a076 in Fortran::runtime::io::ExternalFileUnit::EndIoStatement() ()
(gdb) where
#0  0x000055555557a076 in Fortran::runtime::io::ExternalFileUnit::EndIoStatement() ()
#1  0x000055555556f52d in Fortran::runtime::io::IoStatementState::EndIoStatement() ()
#2  0x00005555555566d4 in _QQmain ()
#3  0x0000555555556772 in main ()
@github-actions github-actions bot added the flang Flang issues not falling into any other category label Oct 7, 2024
@EugeneZelenko EugeneZelenko added flang:runtime crash Prefer [crash-on-valid] or [crash-on-invalid] and removed flang Flang issues not falling into any other category labels Oct 7, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Oct 7, 2024

@llvm/issue-subscribers-flang-runtime

Author: Edoardo Aprà (edoapra)

When compiling the code below with the current flang-new-20 and executing with `MALLOC_PERTURB_=$(($RANDOM % 255 + 1))` and with the file to be opened being not available, the code stops with a segmentation fault. flang-new-18 and flang-new-19 are not affected by this issue. Code ``` program test implicit none logical status open(unit=10,file='./nwchemrc', + status='old',err=9999) write(6,*) ' open ok' stop 9999 continue write(6,*) ' open failed' end ``` gdb stack ``` Program received signal SIGSEGV, Segmentation fault. 0x000055555557a076 in Fortran::runtime::io::ExternalFileUnit::EndIoStatement() () (gdb) where #0 0x000055555557a076 in Fortran::runtime::io::ExternalFileUnit::EndIoStatement() () #1 0x000055555556f52d in Fortran::runtime::io::IoStatementState::EndIoStatement() () #2 0x00005555555566d4 in _QQmain () #3 0x0000555555556772 in main () ```

@klausler klausler self-assigned this Oct 7, 2024
klausler added a commit to klausler/llvm-project that referenced this issue Oct 7, 2024
When an OPEN statement with a unit number fails in a recoverable
manner, the runtime needs to delete the ExternalFileUnit instance
that was created in the unit map.  And we do this too soon -- that
instance still holds some of the I/O statement state that will be
used by a later call into the runtime for EndIoStatement.

Move the code that deletes the unit after a failed but recoverable
OPEN into ExternalIoStatementBase::EndIoStatement, and don't do
things afterwards that would need the I/O statement state that has
been destroyed.

Fixes llvm#111404.
@klausler
Copy link
Contributor

klausler commented Oct 7, 2024

#111454

klausler added a commit to klausler/llvm-project that referenced this issue Oct 7, 2024
When an OPEN statement with a unit number fails in a recoverable
manner, the runtime needs to delete the ExternalFileUnit instance
that was created in the unit map.  And we do this too soon -- that
instance still holds some of the I/O statement state that will be
used by a later call into the runtime for EndIoStatement.

Move the code that deletes the unit after a failed but recoverable
OPEN into ExternalIoStatementBase::EndIoStatement, and don't do
things afterwards that would need the I/O statement state that has
been destroyed.

Fixes llvm#111404.
klausler added a commit that referenced this issue Oct 10, 2024
When an OPEN statement with a unit number fails in a recoverable manner,
the runtime needs to delete the ExternalFileUnit instance that was
created in the unit map. And we do this too soon -- that instance still
holds some of the I/O statement state that will be used by a later call
into the runtime for EndIoStatement.

Move the code that deletes the unit after a failed but recoverable OPEN
into ExternalIoStatementBase::EndIoStatement, and don't do things
afterwards that would need the I/O statement state that has been
destroyed.

Fixes #111404.
ericastor pushed a commit to ericastor/llvm-project that referenced this issue Oct 10, 2024
…11454)

When an OPEN statement with a unit number fails in a recoverable manner,
the runtime needs to delete the ExternalFileUnit instance that was
created in the unit map. And we do this too soon -- that instance still
holds some of the I/O statement state that will be used by a later call
into the runtime for EndIoStatement.

Move the code that deletes the unit after a failed but recoverable OPEN
into ExternalIoStatementBase::EndIoStatement, and don't do things
afterwards that would need the I/O statement state that has been
destroyed.

Fixes llvm#111404.
DanielCChen pushed a commit to DanielCChen/llvm-project that referenced this issue Oct 16, 2024
…11454)

When an OPEN statement with a unit number fails in a recoverable manner,
the runtime needs to delete the ExternalFileUnit instance that was
created in the unit map. And we do this too soon -- that instance still
holds some of the I/O statement state that will be used by a later call
into the runtime for EndIoStatement.

Move the code that deletes the unit after a failed but recoverable OPEN
into ExternalIoStatementBase::EndIoStatement, and don't do things
afterwards that would need the I/O statement state that has been
destroyed.

Fixes llvm#111404.
bricknerb pushed a commit to bricknerb/llvm-project that referenced this issue Oct 17, 2024
…11454)

When an OPEN statement with a unit number fails in a recoverable manner,
the runtime needs to delete the ExternalFileUnit instance that was
created in the unit map. And we do this too soon -- that instance still
holds some of the I/O statement state that will be used by a later call
into the runtime for EndIoStatement.

Move the code that deletes the unit after a failed but recoverable OPEN
into ExternalIoStatementBase::EndIoStatement, and don't do things
afterwards that would need the I/O statement state that has been
destroyed.

Fixes llvm#111404.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] flang:runtime
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants