<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 02/03/2012 04:32 PM, Paul Belanger wrote:
<blockquote cite="mid:4F2BFE11.9080104@digium.com" type="cite">On
12-02-03 09:53 AM, Jonas Kellens wrote:
<br>
<blockquote type="cite">On 02/03/2012 03:48 PM, Paul Belanger
wrote:
<br>
<blockquote type="cite">On 12-02-03 09:05 AM, Jonas Kellens
wrote:
<br>
<blockquote type="cite">On 02/03/2012 02:52 PM, Paul Belanger
wrote:
<br>
<blockquote type="cite">On 12-02-03 07:55 AM, Jonas Kellens
wrote:
<br>
<blockquote type="cite">This is a production server. Will
it affect theserver ?I already have
<br>
"dont_optimize" checked in the debug options.
<br>
<br>
</blockquote>
Yes, reproduce the issue on your test infrastructure. then
generate a
<br>
backtrace [1].
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace">https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace</a>
<br>
<br>
</blockquote>
<br>
How can I reproduce when I don't know what causes the
"deadlock" ??
<br>
<br>
That is part of my question : what can have caused this
"deadlock" ?
<br>
I can go on for weeks without any problem, and then suddenly
there's
<br>
what appears to be a "deadlock".
<br>
<br>
</blockquote>
That's what the backtrace will tell us. If you already have
<br>
DONT_OPTIMIZED compiled on your production server, then attach
gdb to
<br>
the process and generate the backtrace.
<br>
</blockquote>
<br>
I can not reproduce a problem which I don't know what causes it.
<br>
<br>
These seems like the chicken and the egg.
<br>
<br>
There is no core-file generated. It's just the CLI that freezes,
not a
<br>
restart of Asterisk.
<br>
<br>
</blockquote>
You don't need a core-file for a deadlock, you are confusing it
was a crash.
<br>
<br>
Regardless, my previous comment was not complete. There is
nothing you can do until you recompile and enable DEBUG_THREADS
(information available from the previous wiki link). And yes, this
will cause a performance hit to your system,
<br>
</blockquote>
<br>
But in general, are there no general causes to a "deadlock" or the
Asterisk-CLI that freezes ??<br>
<br>
I read on the wiki :<br>
<i>A program is in deadlock when it is in a state where one or more
of its components are waiting on something they will never get. I
don't now the internal structure of Asterisk but I believe it is
multi-threaded. A simple example of a deadlock is if a thread A
were waiting on a resource that thread B has locked, and thread B
is waiting for something thread A has locked.</i><br>
<br>
But I see no such information in my verbose/messages/debug-logfiles<br>
<br>
Can I create a deadlock with bad programming in the dialplan ?? I
have already replaced all macro's with GoSub where possible.<br>
<br>
There were 36 calls... Only 15% CPU (8 cores) and Asterisk uses
about 750000Kb of memory (4 GB available).<br>
<br>
<br>
Jonas.<br>
<br>
</body>
</html>