I recently had a merge with another program and not it seg faults immediately.
It is majority ada and the errors looks like this.
Execution terminated by unhandled exception
raised STORAGE_ERROR : s-intman.adb:136 explicit raise
Call stack traceback locations
<memory addresses here>
Using addr2line on the stack trace shows nothing of importance,
s-intman:?
??:?
??:?
Then when I run it in the debugger it segfaults before it can hit the break at the start of the main function.
Starting program: <program location>
warning: File "/usr/local/gnat-17.2/lib64/libstdc++.so.6.0.22-gdb.py" auto-loading has been declined by your 'auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/local/gnat-17.2/lib64/libstdc++.so.6.0.22-gdb.py
line to your configuration file <gdbinit location>
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file <gdbinit location>
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1"/
[New Thread 0x2aaab1403700 (LWP 2931)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aaab1403700 (LWP 2931)]
0x00002aaaab262fab in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
There is no core dump in either case. So I ran gdb bt to get a backtrace.
#0 0x00002aaaab262fab in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x000000000070105d in system.interrupts.interrupt_manager.bind_handler ()
#2 0x0000000000701940 in system.interrupts.interrupt_manager ()
#3 0x000000000070ef43 in system.tasking.stages.task_wrapper ()
This was confusing to me because it seems like it is segfaulting when it tries to create the process for my program to run.
Last thing I did was run the program with valgrind
valgrind --tool=memcheck --leak-check=yes -v --leak-check=full --show-reachable=yes
and after all of info that spewed out the error that it identified was this
1 errors in contect 1 of 2:
Thread 2 interrupt_manage:
Invalid read of size 4
at 0x53C9FAB: pthread_cond_signal@@GLIBC_2.3.2 (in /usr/lib64/libpthread-2.17.so)
by 0x70105C: system__interrupts__interrupt_managerTK__bind_handler.7016 (in <program location>)
by 0x70193F: system__interrupts__interrupt_managerTKB (in <program location>)
by 0x70EF42: system__tasking__stages__task_warpper (in <program location>)
by 0x53C5E24: start_thread (in /usr/lib64/libpthread-2.17.so)
by 0x7D1F34C: clone (in /usr/lib64/libc-2.17.so)
Address 0x3500004248 is not stack'd, malloc'd or (recently) free'd
Other things to note - Core Dump size was set to unlimited and we specified the dump location - Stack size was st at 64kb, as a test I made it larger, then unlimited and same results.
core size is unlimited and writes
That was all typed by hand, even the outputs of the log, so there MAY be small typos.
This comes from a legacy program that used to run fine. It was upgraded to 64bit requiring new libraries ect. and when it was finally compiling it ran for a bit before running into runtime errors. After the most recent merge this happens. I'm not sure what the issue is and its hard to troubleshoot.
Any help or ideas would be appreciated.
