Ifx .... no stack trace in gdb?

1

Hi,

this code

program test
  implicit none
  integer, allocatable :: x(:,:)
  write(*,*) x(5,5)
end program test

does not produce a stack trace:

user > ifx -O0 -trace -g -check all -debug all tmp.f90 
user > gdb a.out 
GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...
(gdb) run
Starting program: /tmp/a.out 

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]                                                                                                                                                                                                                
Using host libthread_db library "/usr/lib/libthread_db.so.1".
process 92126 is executing new program: /tmp/a.out
[Thread debugging using libthread_db enabled]                                                                                                                                                                                                                
Using host libthread_db library "/usr/lib/libthread_db.so.1".
forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable X when it is not allocated

Image              PC                Routine            Line        Source             
a.out              0000000000489F11  test                        4  tmp.f90
a.out              000000000040A589  Unknown               Unknown  Unknown
libc.so.6          00007FFFF7CCFCD0  Unknown               Unknown  Unknown
libc.so.6          00007FFFF7CCFD8A  __libc_start_main     Unknown  Unknown
a.out              000000000040A455  Unknown               Unknown  Unknown
[Inferior 1 (process 92126) exited with code 0230]
(gdb) up
No stack.
(gdb)

I have more complicated code with deeply nested function calls where essentially the same happens. Am I missing an appropriate ifx flag, or is this a bug?

Thanks

NB: the ifx version is 2024.0.0 20231017

2

But the program has already exited before gdb returns the prompt. It therefore has no process with a stack to check. Can you try a simple program that calls a subroutine to do the same write, but then put a breakpoint at the first executable statement of that subroutine? Then the debugger should still have the process under control and be able to show the stack trace.

3

Hi.

Thank you for your response…

but I wrote in the op that I observed this also in deeply nested code.

In fact I first observed this behaviour when a large project seg faulted somewhere deep inside and I was unable to obtain a stack trace

4

Right, but the essence is that the process simply stops before the debugger has a chance to look into it. The stacktrace you presented for the small demo program does tell where the problem occurs. Does it tell you where it occurs in the actual program? If so, put a breakpoint just BEFORE that code.

5

Hm, come to think of that, maybe leave out the -trace option for the compiler? I an imagine that that inserts code for catching this kind of ulgy bugs and therefore pulling the plug before the debugger can interfere.

6

Hi.

I found the root of the problem.

It is the

-check all

option which kills the stack trace. Dropping it allows gdb to produce the causing code line:

user > ifx -O0 -debug -traceback -g tmp.f90 
user > gdb a.out
GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...
(gdb) run
Starting program: /tmp/a.out 

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]                                                                                                                                                                                                                
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00000000004051b3 in test () at tmp.f90:4
4         write(*,*) x(5,5)
(gdb) up
Initial frame selected; you cannot go up.
(gdb)
7

Ah! Glad you found it. Yes, that is - in retrospect- the cuase. This will build such checks into the program itself. Without the option the debugger gets the chance :slight_smile:

8

I also have written down that the spelling of that option is -traceback, but perhaps this still works.