24426 Memory fault

[tom quach_1]

Hello,

the programmer received this error when he ran (i believe C program)to collect information on a message queue. "memory fault error".
below are some MAX parameters.
Do you think i should increase those parameters.

Thanks in advance.
Tom



The message:-

FMQLOGPATH=/opt/FMQClient/log export FMQLOGPATH;
FMQROOT=/opt/FMQClient export FMQROOT;
FMQCONNECT=SUNDC1 export FMQCONNECT;
#read from test queue
#/SUN/SUNCH/CPROG/fmqread DEVMSMQ
#read from production queue
/SUN/SUNCH/CPROG/fmqread SUNDC1
/tmp/readqch.2005162101012[13]: 24426 Memory fault

some of my MAX setting:
max_thread_proc 256 - 256
maxdsiz 0x10000000 - 0x10000000
maxdsiz_64bit 0x40000000 - 0X40000000
maxfiles 2048 - 2048
maxfiles_lim 4096 Y 4096
maxqueuetime - - 0
maxssiz 0x8000000 - 0X8000000
maxssiz_64bit 0x40000000 - 0X40000000
maxswapchunks 16384 - 16384
maxtsiz 0x4000000 Y 0X4000000
maxtsiz_64bit 0x40000000 Y 0X40000000
maxuprc 1024 Y 1024
maxusers 512 - 512
maxvgs 10 - 10
modstrmax 500 - 500
msgmap 4118 - (2+MSGTQL)
msgmax 8192 Y 8192

[Steven E. Protter]

message queues are shared memory.

They are displayed by the ipcs comannd

ipcs

gpm/glance is a good tool for looking at shared memory use. If you are close to 100% then shmseg and shmmax may need an increase. I have yet to run into a system that fully utilized shared memory, even with Oracle running on it.

SEP

[A. Clay Stephenson]

There is a far greater probability that the problems lies with the code itself. Rather than using "The Force" to diagnose the problem, I suspect that he will have greater success using gdb to examine a stack trace of the core file. Even better would be to compile using -g, let the program crash, and do a stack trace. You should then be able to zero in on the exact offending source line.

[D Block 2]

Tom,

sounds like a programming issue at hand..

can you find the 'core' file related to this process ? how many bytes is this core ? ls -l the file for size..

you can verify the core is related to the executable by matching it using adb command.



# adb executable-file core-file
$c
$q

[tom quach_1]

Thanks-Steven,A.Clay and Tom for the advices.
unfortunately, the person who wrote that code was not here and i only have the executable program.
Is there a shortcut to make the error goes away for now by increase some parameters and do the troubleshooting later.

Regards,
Tom


sema 1 - 1
semaem 16384 - 16384
semmap 8234 - (SEMMNI+2)
semmni 8232 - (NPROC*2)
semmns 16464 - (SEMMNI*2)
semmnu 4112 - (NPROC-4)
semmsl 2048 Y 2048
semume 10 - 10
semvmx 32767 - 32767
sendfile_max 0 - 0
shmem 1 - 1
shmmax 0x4000000 Y 0X4000000
shmmni 200 - 200
shmseg 120 Y 120

[D Block 2 · Accepted solution]

Tom,

here's the thing, the forum guys suggested to study this process as it runs. did you study this process ? run: ps glance, etc.

as far as the kernel tuneables are concerned, this might be a smoking gun..

I don't believe this has anything to due to memory limits, its a core file (kernel aborted this program due to some illegal execution of either an instruction or accessing a memory region that not allowed by this program.)

do you have the source code for this module ? can you rebuild using the debug option (-g). if you can, then this is your best option.

http://www.unix.com/archive/index.php/t-13218.html

[A. Clay Stephenson]

Yes, the shortcut is to not run the program; that will prevent the error. I always suggest the most complicated method of finding and fixing a problem. A slightly more complicated fix would to be assign a random number to the various kernel tunables until you get lucky (or until you create an unbootable kernel) --- either of those scenarios will prevent the program crash. Almost certainly, this has nothing to do with kernel tunables but is a programming error. Seriously, you could use tusc to find the system call that is killing the program but unless you can fix the code there's not much to do. It's barely possible that you are hitting a maxssiz or maxdsiz limit but that is extremely unlikely.

[tom quach_1]

Thanks-A.Clay for a practical suggestion and Tom for a very good link. Understook more about memory error.
Will not mofdify any thing and ask the programmer to check out his coding.

Regards,
Tom

[D Block 2]

tom,

I must suggest you try this TUSC command out. this will show you the System Calls that the program is running.

tusc -a -c -e -f -l -n -p

tusc -f -v -o -p

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/tusc-7.7/

ftp://ftp.cup.hp.com/dist/networking/tools/