SIGSEV when trying to drive AFNI from command line

AFNI Message Board
1

AFNI fails with the following error message:

Fatal Signal 11 (SIGSEGV) received
open_MCW_imseq
SPLASH_popup_image
AFNI_splashup
MAIN_workprocess
AFNI:main
Bottom of Debug Stack
** AFNI version = AFNI_22.1.14 Compile date = Jun 24 2022
** [[Precompiled binary macos_10.12_local: Jun 24 2022]]
** Program Death **
** If you report this crash to the AFNI message board,
** please copy the error messages EXACTLY, and give
** the command line you used to run the program, and
** any other information needed to repeat the problem.
** You may later be asked to upload data to help debug.
** Crash log is appended to file /Users/tevesjb/.afni.crashlog

when running the following test driver as a script, test_drive.sh:
afni -com ‘OPEN_WINDOW A.axialimage’
func

HOWEVER, when run manually on the command line by simply pasting this into the shell and hitting enter, it works normally.

This is low priority since the workaround is so easy.

2

Hi, Josh-

Indeed, the following crashed for me on Mac OS (which you are using):

  • Running “bash test_drive.sh”, when “test_drive.sh” looks like:

#!/bin/sh

afni -com 'OPEN_WINDOW A.axialimage' \
FT_epi_r1+orig.HEAD

… run in the Bootcamp dataset: ~/AFNI_data6/FT_analysis/FT/. (Note that on Ubuntu, it worked fine).

However, this worked for me, with the addition of sourcing ~/.bashrc:


#!/bin/sh

source ~/.bashrc

afni -com 'OPEN_WINDOW A.axialimage' \
FT_epi_r1+orig.HEAD

… so I think it is an issue of how Mac shells source ~/.bash* files (or not, as the case may be) when a script is run.

–pt

3

And as a followup, the crash is happening because of the script’s shell not knowing the DYLD library, so adding the following to the top of the bash script would also prevent the crash (this is what ~/.bash_profile gets set to include):


export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/opt/X11/lib/flat_namespace

Again, I think this is a Mac-specific issue, when using bash or zsh. The startup files might only be read by default when it is a login shell, which I guess the scripts aren’t?

–pt

4

I’m using zsh, and indeed sourcing the zshrc in the script seems to work.

This is a very annoying MacOS quirk, though somehow I haven’t run into it before… And a very interesting failure mode.

Fortunately I already had the DYLD path in my zshrc, so with it sourced things proceed fine.

Thanks for the rapid feedback!

5

Josh-

Yes, all your major shells (bash, zsh, tcsh/csh) should be set up by the @update.afni.binaries install.

We often use tcsh for scripting, which does not have this issue.

–pt

6

Note that if the script indeed ends up using ‘sh’, then the .bash* files will not be looked at. And if there is no #! interpreter directive at the top, it might run as ‘sh’, and therefore need some extra love.

Even if ‘sh’ is a link to ‘bash’, it will probably behave differently when called as sh.

  • rick
7

I do typically place a #! directive at the top, though in these newer days of zsh it looks a bit different from bash-is-default days of yesteryear on MacOS.
I have never experimented with tcsh though.

8

Ah, right. If it’s any consolation, I was actually using “#!/bin/bash” as the shebang in my testing, not just “#!/bin/sh”, which I had initially put when I was writing from a different computer… Sorry for the confusion.

–pt

9

One part of this confusion that’s Mac specific is the blocking of DYLD variables from one shell to another. The path must be inherited; otherwise, it wouldn’t know where to find afni or suma to begin with. This information is for the System Integrity Protection (SIP) that the MacOS introduced in 2015:

“Spawning children processes of processes restricted by System Integrity Protection, such as by launching a helper process in a bundle with NSTask or calling the exec(2) command, resets the Mach special ports of that child process. Any dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes.”