Segmentation fault in Terminal (Leopard)

What I think now is that Terminal has some bugs. It sounds really strange.

About the only way I can think any terminal emulator could affect an applications is how it handles escape sequences. That is to say, some keys send escape sequences to the application, such as the arrow keys, the F1-F20 keys, the Home, End, Page Up, Page Down, etc... kind of keys.

Also there are a few escape sequences that an applications can send to the terminal emulator that cause it to respond with a reply escape sequence, such as what is the current cursor location, the screen size, etc...

Another possibility is if the application uses the "curses" package which behaves differently depending on the setting of the TERM environment variable. And in this case Terminal may be using a different TERM setting than iTerm. If they are different, try setting Terminal's TERM environment variable the same as iTerm's

export TERM=??????

First, iTerm is a nice terminal emulator, and it is what I use every day. I spend lots of time in iTerm. So continue using it if it gets the job done.

Are all the environment variables the same when running Terminal vs iTerm?

Does GAP segfault and you are back at the shell prompt? If so, it is a bug in GAP that is being uncovered by using Terminal. That may be caused by Terminal sending an escape sequence that GAP is not prepared to handle.

If Terminal dies and you have to restart Terminat, then Terminal has a bug and you should report it to Apple via <http://www.apple.com/feedback>

No matter where the bug is, this does not get your work done. So I would suggest continuing with iTerm.

The following iTerm environment variables do not exist for your Terminal environment:

# found in iTerm environment variables (NOT in Terminal)
COLORFGBG=0;15 # seems to be Color Foreground/Background info
LANG=it_IT.UTF-8
LCCOLLATE=itIT.UTF-8
LCCTYPE=itIT.UTF-8
LCMESSAGES=itIT.UTF-8
LCMONETARY=itIT.UTF-8
LCNUMERIC=itIT.UTF-8
LCTIME=itIT.UTF-8

I do not know if this would have an affect on GAP or not, but it is a difference that affects how programs process strings, print, terminal reads, etc...

Have you tried setting these environment variables in Terminal before using GAP? I'm not sure that they would or would not change things, but it is a difference related to date input/output handling which is where Terminal is involved with GAP.

And like I said, there is very little that Terminal can do to directly affect the process GAP. It does not provide any system services, it does not provide any memory management, it does does not provide the process GAP runs in, it actually does very little.

The only connection between GAP and Terminal is the standard in, standard out, and standard error I/O ports. That basically means the characters sent back and forth between GAP and Terminal. And the most likely type of characters that could cause trouble would be escape sequences, especailly query sequences from GAP to Terminal and where Terminal reponds to the query. If the response in Leopard Terminal is different from the response in Tiger, then that might expose a bug in GAP that GAP is not prepared to handle the differently formatted escape sequence.

This difference could be totally within the ANSI terminal emulator standards, but not typical of other terminal emulators send, or it could be a bug in Terminal. But regardless of what Terminal sends, no well written applications should ever trust the input it receives from the outside world, and thus if it crashes because of input, then it is the fault of the application.

For example, I write file system code for a living (Unix and Linux systems). If I decided to crash the operating system because someone misspelled the name of a file, no one would be happy, and while the misspelling was on the part of the user and thus their error, that is no excuse for code I write to die because of bad input. And this applies to GAP.

I would suggest you report the GAP seqfault to the GAP developers so that they have a chance to correct it. And if you really think it is an Apple Terminal error as root cause, give feedback to Apple via the previously mentioned feedback link.

And in the meantime, use iTerm so you can get your work done.

Now, do you think that an application can have such errors depending on the size of the window?

Yes. This is either a GAP error or an error with some library software GAP is using to control the information it displays on the screen.

In any event, it looks like this is not related to the terminal, but a problem in the application or the run-time libraries used by the application, all of which is totally independent of the terminal emulator.

For example, the application could have sized some line buffer to 255 characters (a common size in programs), and when the lines for the screen were 266 characters, the buffers overflowed, variables totally unrelated to displaying text got corrupted. If that buffer was on a subroutine stack, the overflow could have corrupted a return address and when the routine returned it might have jumped into never-never-land. Or an adjacent memory location was a pointer, and when the code attempted to use the pointer after it was corrupted, it accessed memory outside the applications allowed space.

This is the kind of bug you report to the GAP developers along with information on how to reproduce it.