H.1 List of Run Time Errors

This section presents an alphabetical list of fatal error messages, as generated by error(3NEMO). Although this list is not meant to be complete, it hopes to report on the most common bizarre errors found when using NEMO, and their possible cures. The ones not listed here should be descriptive enough to guide the user to a solution. Sometimes execution errors can be better understood when the DEBUG environment variable is set to a high(er) value, or the debug= system keyword is added to the command-line. See Appendix  on it's use.

Now the list of error messages and their possible cures:

assertion failed: file f line n

The program was compiled with an active assert(2) macro. An expression was expected to be true at this point in the program. Program exits when this was not the case. An infamous failed assertion is file load.c line 91 or thereabouts, part of the hackcode1 N-body integrator. Two particles were too close (or on top of each other) such that space could not be subdivided within 32 levels of the oct tree. There is no good solution to this problem.

findstream:     No free slots

Too many open files. Either the program didn't cleanup (close) its files after usage, or your current application really needs more than the default 16 which is #defined in filesecret.h by the macro StrTabLen. Recompile the filesecret.c and the appropriate application tasks.

get_tes:        set=A tes=B

This points to a programming error or error in the logic during filestruct(3NEMO) I/O. During program execution a hierarchical set A was requested to be closed, but the program was still within set B (set B had not been closed yet).

gethdr:         ItemFlag = 0164

Input was attempted on a file assumed to be in old filestruct(5NEMO) format. Apparently it was not, file may also have been in new filestruct format. Hints: Try tsf(1NEMO), hd(1NEMO), od(1) and as last resort more(1).

gethdr:         bad magic: 0164

Input was attempted on a file assumed to be in filestruct(5NEMO) format. Apparently it was not. Hints: Try tsf(1NEMO), hd(1NEMO), od(1) and as last resort more(1).

loadobj:        file must be in .o format

It is possible that the non-portable dynamic object loader (loadobj.c) indeed proves to be non-portable here. Either you requested a wrong file, which is not in object format, or this UNIX version has a different object file structure. Cure: a lot of hacking in loadobj.c, assuming no pilot error.

loadobj:        undefined symbol _XXXX

There are three possible causes. It might be that you have just supplied a 'new' object file to a program, which happens to call a function which was not linked in by the calling program. Find out in which filestructure 'group' (Nbody, Orbit, Image) your invoked program falls, and add appropriate dummy code to the library function. E.g. in the case of potential(5NEMO) data files, you might have to add a specific math function to $NEMO/inc/mathlinker.h, or add some coding to the end of $NEMO/src/orbit/potential/potential.c and rebuild the appropriate orbit(1/3NEMO) library/commands. The standard UNIX utility nm(1) help finding all undefined symbols in an object file. Cross check this with the executable.

The second possibility is that the executable was stripped, i.e. it had no symbol table. Try nm(1) to find out, or use file(1).

The last cause is much more serious: the non-portable dynamic object loader (loadobj.c) indeed seems to be non-portable here. This might mean serious hacking in loadobj.c, we cannot give any advice on this right now.

loadobj:        word relocation not supported

It is possible that the non-portable dynamic object loader (loadobj.c) indeed proves to be non-portable here. This might mean serious hacking in loadobj.c.

makecell:       need more than XX cells; increase fcells=

This is actually sort of a pilot error, but may sound a bit obscure to a beginning user. Space for cells used in the hackcode force calculation is allocated dynamically, as well as for the particles. 'fcells' is the ratio of allocated cells to particles and is a parameter to most programs who use the hackcode force calculation. For small N-body systems (less then about 100) this ratio may have to be increased, 2 usually is enough. Note that in the regime where fcells is required larger, the hackcode force calculation is usually not the most efficient method to compute forces anyhow.

Malformed or non-terminated attribute-value list.

This error is actually from one of the Sunview routines, and is a result of a too large buffer to display (in header or 'below' a mouse button). It will happen when the number of files in a directory is too large to display below the Run button in mirtool.

mysymbols:      file must be executable

It is possible that the non-portable dynamic object loader (loadobj.c) indeed proves to be non-portable. The program which you just executed does not have the executable format the dynamic object loader thinks it should have.

No man entry for XXX.Y

No online manual page for this, although perhaps the MANPATH environment variable has not been properly set, or your UNIX version does not support multiple man-root directories, in which case consult the manual page of man(1). The SUN OS does, as well as BSD 4.3 (?). Perhaps a special man-script/alias with an extra -M flag needs to be installed in this case if MANPATH is not supported. See also the lpath variable on some systems.

put_snap_XXX:   not implemented

Here 'XXX' may be 'key' or 'aux' or something else. You have an old version of the code, while the datastructure of the snapshot has an 'XXX' (You may confirm this with tsf(1NEMO). Recompile the program with a more recent version of $\langle$snapshot/put_snap.c$\rangle$ and possibly $\langle$snapshot/body.h$\rangle$.

readparam:      No interactive input allowed

The keyword help= or the equivalent environment variable HELP has been assigned a digit to request interactive input. In addition you requested some file I/O through either redirection or piping. Get rid of at least one of them.

rsh:            could not execute rsh

Program could not execute itself on a remote machine. It may have various reasons for failing. The rsh program may not exist on your host, in which case the getparam(3NEMO) might as well have been compiled without the REMOTE flag. The other possibility is that the .rhosts file on your system does not contain an entry for the machine you wanted to rsh to. In interactive usage it will then ask for a password, executed through execvp(3) normally fails. A third possibility is that the remote machine did not have the executable present.

Badly placed ()'s

You tried to pass an expression with parentheses, but since the UNIX shell gives them special meaning, you need to ``escape'' them from the shell, e.g.

	% snapplot in=snap001 xvar=r yvar=log(aux)

you need to type any of:

	% snapplot in=snap001 xvar=r 'yvar=log(aux)'
	% snapplot in=snap001 xvar=r yvar=log\(aux\)