howto pstack running freeradius process

[John Dennis]

On 07/24/2009 04:27 AM, George Chelidze wrote:
> On Fri, 2009-07-24 at 08:08 +0200, Alan DeKok wrote:
>> George Chelidze wrote:
>>> I didn't say it's an issue with freeradius.
>>    If it's not a FreeRADIUS issue, then the question doesn't belong on
>> the list.
>
> I have just realized that this question should have been posted to
> freeradius-devel list. Sorry for mistake.
>
>>    You're asking us to support (for free) a module you wrote, and/or an
>> OS that someone else wrote.
>>
>>    Why?
>
> What kind of answer you would like to get? I am afraid I missed
> something while building freeradius the way I did so I asked what I
> asked. If I knew that I have built freeradius with enough parameters to
> get the stack trace and I can't get it because I have some other OS
> related problem I would never asked this question on this list. I still
> do not know it, so if someone can give me a hint, I'll be thankful.

I have to agree with Alan, this is not a FreeRADIUS issue. It is clearly 
an OS and software development environment issue. You haven't even 
stated what OS and architecture it is and your description of the error 
is vague at best. The man page for ptrace states it has architecture 
specific limitations. You built a local copy using your own toolchain 
and installed it in in a non-standard location, the ball is in your court.

Here is a hint which is appropriate for Linux. I assume the process is 
aborting, if so the easiest thing to do is port-mortium analysis on a 
core dump using gdb with the assumption you built everything with 
debugging symbols. Normally Linux does not generate core dumps when a 
process aborts, you have to ask it to generate the core dump. This is 
done with "ulimit -c NNN" where NNN is the maximum size of the core 
dump, by default its zero. Run the server, allow it to crash, then run 
gdb on the generated core file and the server executable.

The other thing you can do attach gdb to the running process and wait 
for things to go boom, you'll have a complete stack trace and can 
examine state the moment it happens, in fact this is really just an 
interactive version of the core dump approach, but without the core 
dump. It has an advantage of being able to pause the process before 
things go wrong and examine state. Just one gottcha, because FreeRADIUS 
uses loadable modules you won't be able to set break points in modules 
before they're loaded unless you tell gdb you need to do this, "set 
breakpoint pending on" is your friend in this regard.

HTH,

John


-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/