AFNI issues (twofold)

AFNI Message Board
1

Hello! I have AFNI set up on my computer and it runs normally when I’m doing a fairly straightforward such as making a resection mask, but when running any script utilizing AFNI I get this error message:

Fatal Signal 11 (SIGSEGV) received
Last STATUS: creating top_form
AFNI_make_widgets
new_AFNI_controller
MAIN_workprocess
AFNI:main
Bottom of Debug Stack
** AFNI version = AFNI_22.0.21 Compile date = Mar 20 2022
** [[Precompiled binary macos_10.12_local: Mar 20 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/haydayea/.afni.crashlog
\n+* Removing temporary image directory ‘/Volumes/Shares/NEU/Projects/fMRI/p225/screenshots/__tmp_chauf_4DLGregSic2’.\n
[1] + Done Xvfb :201 -screen 0 1024x768x24

++ DONE (good exit)
see: /Volumes/Shares/NEU/Projects/fMRI/p225/screenshots/vf_20220329_153553_top10*

Additionally, when I run AFNI (regardless of whether I am opening a file in the shared drive or on my local machine), the AFNI GUI opens button-by-button, in a way that is painfully slow and does not happen on my laptop which should have the same exact settings. I am hoping that both are connected to some sort of setup issue; have you seen anything like this?

Thanks,
Elena

2

I’ve seen performance issues like this occasionally on recent Macs. In the Display preferences, set the refresh rate to 60Hz. In the XQuartz display preferences, set the number of colors to Thousands and restart XQuartz.

https://github.com/XQuartz/XQuartz/issues/166

3

Thank you! Those fixes did fix the loading issue. Do you have any input on the “Fatal Signal 11” error message that I am receiving when running AFNI commands in a script?
Thanks,
Elena

4

Does the afni GUI start by itself? Is this problem limited to the Xvfb implementation that is used in the scripting?

Xvfb is used by @chauffeur_afni and other related scripts in AFNI. These are mostly written in tcsh. Configure the various shells to be configured to set the DYLD_LIBRARY_PATH to the path of library files that are provided with XQuartz. For example, in your .bashrc and .zshrc files in your home directory, you may want to add lines like this one:

export DYLD_LIBRARY_PATH=/opt/X11/lib/flat_namespace

In tcsh, you would modify your ~/.cshrc (~ is the home directory) similarly to contain

setenv DYLD_LIBRARY_PATH /opt/X11/lib/flat_namespace

5

The error doesn’t necessarily happen when the AFNI GUI opens from a script and it does open normally in other scripts. Looking back at my crash log, it looks like I always get this error after the last status is
Last STATUS: creating top_form
AFNI_make_widgets
new_AFNI_controller
MAIN_workprocess
AFNI:main.
I apologize because I’m an IRTA that’s very new to AFNI, so I don’t know if there’s an easy fix for this and I’m not entirely sure what you mean by Xvfb implementation.
Thanks,
Elena

6

Sorry, I edited my previous comment to give some more details.

7

Hi, thanks for clarifying that for me! I do have that line in all of the aforementioned .rc files, so I don’t think that’s the issue.
Thanks,
Elena

8

Hi Elena,

As a test, would you please open a new terminal window and run the following commands?
For any ‘suma’ command, wait to see that it fully opens, then close the suma window, then proceed.

tcsh
suma
bash
suma
zsh
suma

Do any of the suma commands fail?
Once you are finished, it is okay to exit out of that new terminal window.

Thanks,

  • rick
9

Hi,
Sorry, just seeing this message. Yes, the suma command fails in the tcsh shell – I get the same “Fatal Signal 11” (pasted below) that I had been receiving when running afni commands.
Thanks,
Elena

Fatal Signal 11 (SIGSEGV) received
SUMA_X_SurfaceViewer_Create
suma
Bottom of Debug Stack
** AFNI version = AFNI_22.1.02 Compile date = Apr 6 2022
** [[Precompiled binary macos_10.12_local: Apr 6 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/haydayea/.afni.crashlog

10

I will send you direct email about this, if that is okay.
It would be good to resolve.

  • rick
11

To add closure on this, the easy bit was fixing a couple of typos. The more surprising bit was realizing that .bashrc is NOT processed in a non-interactive shell.
On a mac, in order to run afni/suma/etc. from a non-interactive shell (such as from a script), one must take an extra step to pass on the DYLD vars.

For example, it might be good to put something like this in the .bashrc file:

export BASH_ENV=~/.bash_dyld_vars

While ~/.bash_dyld_vars could look like:

export DYLD_LIBRARY_PATH=${DYLD_LIBRARY_PATH}:/opt/X11/lib/flat_namespace
  • rick
12

For the benefit of future generations (and possibly of present ones, such as myself), does this extra consideration only apply for bash/zsh, but not for tcsh/csh?

–pt

13

It is only in the case of bash.
For csh/tcsh, .cshrc/.tcshrc are processed for non-interactive shells, too.

zsh seems more organized and enhanced than bash (of course, it is newer).
zsh always sources .zshenv, while .zshrc is for interactive shells (read next).
So DYLD variables should certainly go in .zshenv, rather than .zshrc.
If it is a login shell, .zlogin is also read (akin to .login for csh/tcsh).

I am updating this info in:

afni_system_check.py -help_dot_files
  • rick
14

Merci beaucoup!

–pt