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 <[email protected]>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
