Showing results for 
Search instead for 
Did you mean: 

About the output of tusc

Occasional Visitor

About the output of tusc


I am new to this forum. I attached a output of tusc of a select command which fails. Can anyone advice me how to analyse this tusc output and to rectify the errors ERR#12 ENOMEM and ERR#25 ENOTTY
Steven E. Protter
Exalted Contributor

Re: About the output of tusc


This is normally a problem with a terminal device (NOTTY) not being correct. If this involves oracle, you need to set up an environment, including a terminal, even when firing up batch style processes in the background.

Steven E Protter
Owner of ISN Corporation
Honored Contributor

Re: About the output of tusc

After the ENOMEM errors, the command is doing the analysis for you. It appears to be trying to print an error message:

jBase: Unable to allocate 279442109 bytes, errno = 12 at jlibBStore.c,347(ENQSELCRITSUBS.h,1)

It's very clearly saying it needs about 270 megabytes more memory. Run "ulimit -a" and "ulimit -a -H". Is it hitting any of those limits, or are the machine's memory and swap completely in use?

If it's the ulimit, evaluate whether you have enough system resources (=memory and swap) to raise the limit. If not, add some memory to the server before raising the ulimit.

In this case, the ulimit just stopped the problem before it caused system-wide trouble. If you just increase the limit without actually having the memory to support the increased limits, the system-wide lack of memory may cause other unrelated processes to die, and that may make the machine unresponsive: if inetd (and sshd, if you have it) die in an out-of-memory situation, you need console access to recover. A situation like that is generally so messy that it might be easier to just reboot...

If the problem is that there is not enough physical memory nor swap free, the solution is to add some memory. If your need is temporary and you can afford to take a *major* performance loss, you can just add more swap instead.

After the error message, something interesting happens: the program gets a SIGSEGV. The siginfo says "faulting addres: 0". My guess is that after trying to allocate more memory, receiving a failure indication, and printing the error message about it (explained above), the program just tried to use the memory anyway. That is a stupid thing to do. Instead of gracefully rolling back the transaction and reporting "the system is overloaded" (or whatever is appropriate) to the end user, the program is now firmly on its way to crash.

The ENOTTY error does not seem to be harmful.

Just before the error, the program is opening a file /usr/jbc/tmp/jbase_error_trace. Note that it gets 46 as the response: that's the file descriptor. The next system call is lseek, which gets the same file descriptor as the first parameter. The same is true about the ioctl system call which produces the error... so now we know the ioctl was targeted to /usr/jbc/tmp/jbase_error_trace, which obviously is not a terminal device, so the ENOTTY return code is absolutely correct.

My guess is that there is just one error output function in the program, and nobody has thought about what happens if the error message is redirected to a file. The program is simply ignoring the errors from a terminal-related system call, because it is not essential for that call to succeed. The error happens in a point where the program is already reporting a critical error: as it's essential that the error reporting code is as simple and robust as possible, this ignoring of ENOTTY error is acceptable. Getting the error message nicely wrapped according to the terminal width is not important: getting the error information to the people who can fix the problem _is_ essential.

Of course, the neater way would be to test whether the target file descriptor is a TTY or not, and then skip the ioctl call if the target is not a TTY.

Dennis Handly
Acclaimed Contributor

Re: About the output of tusc

>MK: The ENOTTY error does not seem to be harmful.

Right. You don't have to worry about ENOTTY. This could occur because stdio needs to figure out the buffering and handles TTYs special.

>MK: the neater way would be to test whether the target file descriptor is a TTY or not, and then skip the ioctl call if the target is not a TTY.

That's what fread/fwrite(3) is doing. It has to call ioctl (really isatty(3)) to find this.