Posted: Fri May 22, 2009 7:24 am Post subject: [asterisk-dev] How to find crashing problems (cause maybe do
Hi all,
I am writing on an own conference bridge which should be used for a real
radio simulation for the open source flight simulation FlightGear
(current Asterisk module code can be found at
https://sourceforge.net/projects/appfgcom/). The basic idea behind is
taken from app_conference: Every caller has its own member thread where
frames are put onto a member-in-queue. A conference thread than mixes
the frames from every member-in-queue together in every meber-out-queues
(currently not based on their virtual distance). From
themember-out-queue the meber-threads picks the frames and sends them to
the channel and frees them.
Because this is my first development for Asterisk it seems that have
some problems of understanding some basic technology. At the current
state the conference bridge works - I can place several calls and mix
them in slinear together.
But I get crashes like the following when running two or three calls for
some time:
I know what this means - but I don't know why this happens... Before
every call to free() (or ast_frfree()) I check the pointer against NULL
but it seems that frames are freed and the pointer isn't set to NULL.
What I found out is that I had a dynamic sleep time at the start of
every conference-mixing-loop. This was about 20000 usec (with usleep).
It seems that decreasing this time to 1000 usec helps a little bit - the
crash is not after 2 minutes or so but after 10 or 15 minutes...
Has anyone an idea what I can do to find this problem?
Are there helpful tools for this kind of problem?
Posted: Fri May 22, 2009 7:36 am Post subject: [asterisk-dev] How to find crashing problems (cause maybe do
Dear Holger,
Three points here. More so related to the language C instead of asterisk:-
free() does *NOT* set the ptr to NULL. It just marks the allocated memory as unused. The ptr will still keep pointing to the same address. Its the programmer's responsibility to ensure that ptr is not used again in this state.
From the manual page of free (defined in stdlib.h),:-
""free() frees the memory space pointed to by ptr, which must have been returned by a
previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has
already been called before, undefined behaviour occurs. If ptr is NULL, no opera-
tion is performed. ""
So, if ptr is NULL, you do not need to perform a check anyways, because free() will handle it cleanly.
Thirdly, by putting some simple debug logs just before free() [Just print the address being free'd], you can determine if or not, you are calling free() on the same ptr twice.
Btw, what (and why) design or architectural differences are you making from app_conference ?
On Fri, May 22, 2009 at 1:43 PM, Holger Wirtz <wirtz@dfn.de (wirtz@dfn.de)> wrote:
Quote:
Hi all,
I am writing on an own conference bridge which should be used for a real
radio simulation for the open source flight simulation FlightGear
(current Asterisk module code can be found at
https://sourceforge.net/projects/appfgcom/). The basic idea behind is
taken from app_conference: Every caller has its own member thread where
frames are put onto a member-in-queue. A conference thread than mixes
the frames from every member-in-queue together in every meber-out-queues
(currently not based on their virtual distance). From
themember-out-queue the meber-threads picks the frames and sends them to
the channel and frees them.
Because this is my first development for Asterisk it seems that have
some problems of understanding some basic technology. At the current
state the conference bridge works - I can place several calls and mix
them in slinear together.
But I get crashes like the following when running two or three calls for
some time:
I know what this means - but I don't know why this happens... Before
every call to free() (or ast_frfree()) I check the pointer against NULL
but it seems that frames are freed and the pointer isn't set to NULL.
What I found out is that I had a dynamic sleep time at the start of
every conference-mixing-loop. This was about 20000 usec (with usleep).
It seems that decreasing this time to 1000 usec helps a little bit - the
crash is not after 2 minutes or so but after 10 or 15 minutes...
Has anyone an idea what I can do to find this problem?
Are there helpful tools for this kind of problem?
This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender.
Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Drishti-Soft Solutions Pvt Ltd ("Drishti") unless sent with that express intent and with due authority of Drishti.
Drishti has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.
Posted: Fri May 22, 2009 12:28 pm Post subject: [asterisk-dev] How to find crashing problems (cause maybe do
On Friday 22 May 2009 03:13:09 Holger Wirtz wrote:
Quote:
But I get crashes like the following when running two or three calls for
some time:
--- cut here ---
...
-- Hungup 'IAX2/193.174.1.6:4569-11496'
*** glibc detected *** asterisk: double free or corruption (out):
0xb5b75778 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7d9b215]
/lib/libc.so.6(cfree+0x9c)[0xb7d9caec]
...
--- cut here ---
Has anyone an idea what I can do to find this problem?
Are there helpful tools for this kind of problem?
Valgrind is an excellent tool for figuring out problems like this. If you
like, please download my presentation from Astricon 2008, starting on
slide 39, which details the exact valgrind output you're likely to see, as
well as what was done about it. It's a real-life debug session that is
exactly the scenario you have and should be completely relevant to your
debugging.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum