topic Re: app crashing due to SIGSEGV .. in Operating System - HP-UX

app crashing due to SIGSEGV ..

someone_4 — Wed, 23 Jan 2002 18:00:39 GMT

I have a radius app that core dumbs ..

core: core file from 'radiusd' - received SIGSEGV

Well I have found out that SIGSEGV is an Invalid memory reference. The radius is having some kind of memory issue.I was thinking of starting with increasing the kernel parameters maxdsiz, maxssiz and or maxtsiz. Maybe 2 to 3 times higher as I read on another post. But when I got in there thoose kernal params are not numbers. They are like
0x0000000040000000
How do I increase that?
And am I going the right route over all with this issue.

THanks
Richard.

Re: app crashing due to SIGSEGV ..

Christopher McCray_1 — Wed, 23 Jan 2002 18:04:04 GMT

I believe that through sam, you can specify another formula or value by selecting the option after highlighting the parameter and selecting modify. Otherwise, you can use a calculator like I sometimes do - enter in the number and hit hex.

Hope this helps

Chris

Re: app crashing due to SIGSEGV ..

Krishna Prasad — Wed, 23 Jan 2002 18:11:23 GMT

You can add a fixed number in the /stand/system file or via sam.

You can also increase the number by

replacing the 0x0004 with 0x006 for instance and it will increase the parms.

Re: app crashing due to SIGSEGV ..

someone_4 — Wed, 23 Jan 2002 18:13:45 GMT

So the old
0x0000000040000000

would be

0x0000000080000000

And that would increase it by 2x?

Richard

Re: app crashing due to SIGSEGV ..

James R. Ferguson — Wed, 23 Jan 2002 18:25:21 GMT

Richard:

The notation (0x) denotes hexadecimal values. You might want to convert to decimal to decide if a new value is "reasonable", and then enter the new value in hexadecimal.

Regards!

...JRF...

Re: app crashing due to SIGSEGV ..

A. Clay Stephenson — Wed, 23 Jan 2002 18:31:34 GMT

Hi Richard:

It is rather rare for a need to increase maxtsiz but in almost all cases 256MB-512MB is plenty. Maxssiz is almost always fine at 32MB or , in general, the programmer is an idiot (unenlightened, mentally challenged, you pick).
Maxdsiz is probably your boy. The danger to increasing any of these to really big values is that a process can then grab all the resources and bring a box to it's knees.

Bear in mind, that your crash may have nothing to do with resource limits but may instead simply be a programming error.

Regards, Clay

Re: app crashing due to SIGSEGV ..

Kevin Wright — Wed, 23 Jan 2002 19:13:52 GMT

you need to look through the core file with strings and look for any error messages, I just had a similar problem on 11i, and it was a libc patch.

Re: app crashing due to SIGSEGV ..

someone_4 — Wed, 23 Jan 2002 20:16:00 GMT

Here is the only thing that really stuck out when I did
strings core | more

HP3000 mode packed decimal error
Check true/false trap
Signal 1: hangup
Signal 2: interrupt
Signal 3: quit
Signal 4: illegal instruction
Signal 5: trace trap
Signal 6: abort
Signal 7: not enough memory available
Signal 8: floating point exception
Signal 9: kill
Signal 10: bus error
Signal 11: segmentation violation
Signal 12: bad argument for system call
Signal 13: write on a pipe with no one to read
Signal 14: alarm clock trap
Signal 15: software termination signal
Signal 16: user defined signal 1 trap
Signal 17: user defined signal 2 trap
Signal 18: death of a child
Signal 19: power fail
Error<2>: Out of memory while tracing stack.
Error<3>: Out of memory while tracing stack.

Leads back to a memory problem .. right??

Re: app crashing due to SIGSEGV ..

A. Clay Stephenson — Wed, 23 Jan 2002 20:25:53 GMT

Hi Richard:

No, that does not necessarily lead back to a memory problem. Your strings command is simply dumping text error messages. I should say the text for potential error messages. These strings are no more meaningful than Name, Address, Phone Number. It's just program data. You will have to dig deeper.

Re: app crashing due to SIGSEGV ..

Kevin Wright — Wed, 23 Jan 2002 20:37:25 GMT

search through the strings output for errno, it should have something like that in the output..IE mine was an ld error, which lead me to the linker, which lead me to a libc patch, and that fixed the problem...

Re: app crashing due to SIGSEGV ..

someone_4 — Fri, 25 Jan 2002 17:35:14 GMT

Ok digging in a little deeper .. I found this .. and it seems like nis/memory issue
Would it be save to start with Maxdsiz ? Or should I keep digging?

mp: no free space
__itom1
__itom2
inet
inet
inet
inet
inet
/usr/lib/
/usr/lib/%s
_netdir_getbyname
_netdir_getbyaddr
_taddr2uaddr
_uaddr2taddr
_netdir_options
n2a: memory allocation failed
n2a: successful completion
n2a: hostname not found
n2a: service name not found
n2a: access denied for shared object
n2a: attempt to free unknown object
n2a: bad arguments passed to routine
n2a: unknown option passed
n2a: control operation failed
n2a: system error: %s
n2a: unknown error: %d
%s: %s
n2a: error
tpi_clts
tpi_cots
tpi_cots_ord
tpi_raw
/etc/netconfig
NETPATH
no error
out of memory
routine called before calling setnetpath() or setnetconfig()
cannot open /etc/netconfig
%s %d %s %d
error in /etc/netconfig: field
of line %d
netid not found in /etc/netconfig
no more entries in /etc/netconfig
unknown error
%s: %s
NIS+:NisDirCacheEntry()::myConstructor - xdr_directory_obj failed
NIS+: NisDirCacheEntry::write_info :alignmemt error
NisDirCacheEntry::write: xdr_directory_obj failed
CacheBind: xdr_directory_obj failed
possible loop detected in name space (directory name:%s
NIS+: NisBindCache runtime error: pure virtual function print() called
/var/nis/NIS_SHARED_DIRCACHE
%s.tmpXXXXXX
NIS+: writeColdStartFile cannot open file '%s' for writing: %m
NIS+: writeColdStartFile: fdopen() failed for '%s': %m
NIS+: writeColdStartFile: could not chmod cold_start file: %m
NIS+: writeColdStartFile: xdr_directory_obj failed
NIS+: writeColdStartFile: error while renaming '%s' to '%s': (%m)
/var/nis/NIS_COLD_START
/var/nis/NIS_COLD_START
/var/nis/NIS_COLD_START
nis_cast: no memory
nis_cast: t_open: %s:%m
nis_cast: t_bind: %m
nis_cast: t_alloc: %m
nis_cast: ignoring host %s
nis_cast: no memory
nis_cast: no memory
nis_cast: %s: address not known
nis_cast: couldn't find addresses
nis_cast: select: %m
nis_cast: t_rcvudata: %s:%m
nis_cast: t_rcvudata: %s: buffer overflow
nis_cast: no memory
nis_cast: no memory
nis_cast: no memory
nis_cast: Unable to convert universal address %s for %s (%d).
nis_cast: accounting error.
nis_addmember: Out of memory
%s.%s
nis_addmember: Out of memory
%s.%s
nislib:insert_name out of memory.
nislib:insert_name out of memor
__nis_isadmin: buffer too small
%s.org_dir.%s
__nis_isadmin: could not lookup '%s' table
__nis_isadmin: not a table object
rpcbind
!z%s.%s
%s.%s%s
%s.%s
NIS_PATH
NIS_DIRECTORY
%s.%s
Success
Probable success
Not found
Probably not found
Cache expired
NIS+ servers unreachable
Unknown object
Server busy, try again
Generic system error
First/Next chain broken
Permission denied
outgoing connection pending
incomming connection pending
data transfer
outgoing release pending
incomming release pending
unknown state
max number of poll threads already running
net_init failed
out of memory
parameter error
no poll thread available
max number of listen threads already running
Host name not found in /etc/hosts
Internal error - data structure
Not in correct state for operation
Message with zero length found
service name not specified
connection rejected - too many users, or invalid user name
REQUESTS in TBCONFIG greater than %d

Re: app crashing due to SIGSEGV ..

Bill Hassell — Wed, 11 Jun 2003 00:33:12 GMT

The SIGSEGV error is within the program. As you guessed, it is a memory issue, but unless the program very badly written, not related to kernel parameters. It is a segmentation violation where the program is trying to use a non-existant portion the program's memory. That is very different than asking for more memory with a malloc request and not getting it--unless the program never checks for success and starts using the memory, a common newbie error.

Without tracing the program's execution, there is nothing you can determine about the nature of the error. The strings command is simply dumping out every ASCII string in the program or core file--the result has nothing to do with the program's problem.

As far as the kernel parameters, 0x0000000040000000 is indeed a number, in hexadecimal. SAM decodes this for you right underneath and 0x40000000 is 64 megs. Just delete the 0x... number and replace it with a desired value, perhaps 500 megs (ie, 500000000). maxdsiz is the only one you need to change. maxtsiz and maxssiz are likely just fine--unless the program has very special requirements, and of course, the programmer will have documented those kernel values for you.

Re: app crashing due to SIGSEGV ..

U.SivaKumar_2 — Wed, 11 Jun 2003 07:41:29 GMT

Hi,

SIGSEGV is generated when a process causes stack overflow.

kernel parameter for 32 bit kernel : maxssiz is directly related to the stack.

kernel parameter for 64 bit kernel : maxssiz_64bit is directly related to the stack.

Increasing it will help to solve the problem.

I hope you are running radiusd daemon as some other unprivileged user for security purpose.

Then check the Resource limits set for that user ( EUID with which daemon runs )and also for root using this command.

ulimit -s

it should give the stack size limit for the user.

eg:

8192 ( in kbps )

Try Increasing the user's ulimit stack size limit and start the daemon .

ulimit -s 28000

regards,

U.SivaKumar