Posted: Fri May 22, 2009 8:18 am Post subject: [asterisk-dev] How to find crashing problems (cause maybe do
Hi Prince Singh,
thanks for your fast response.
Prince Singh wrote:
Quote:
Dear Holger,
Three points here. More so related to the language C instead of asterisk:-
1. 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.
Yes. That's why I think tehere is a problem with a freed pointer that
isn't set to NULL...
Quote:
2. 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.
And I think there is no way to find out if the pointer was freed or not
before.
Quote:
3. 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.
Yep - this is really a good idea. I am writing C code not for a long
time so I have to learn some (simple) tricks to get forward in debugging.
Quote:
Btw, what (and why) design or architectural differences are you making from
app_conference ?
In fact I first tried to use app_conference and patch it for my needs
but I failed to set up my own mixing based on distance between the
members in a conference beacause app_conference has very much code which
isn't needed for app_fgcom (e.g. video and video switching).
The goal of app_fgcom is not only to mix together every member of a
conference but to collect further data from the clients (=fgcom - an
iaxclient based VoIP middleware for FlightGear). In fact these data is
the position of the plane which is send with IAX text messages.
app_fgcom collects these data and caculates a distance matrix. The sound
in a conference is mixed together with a (currently not written)
algorithm which takes care of distance. So there may be members in the
same conference (=frequency) but they only can hear the others when they
are in range.
On Fri, May 22, 2009 at 1:43 PM, Holger Wirtz <wirtz@dfn.de> wrote:
> 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:
>
> --- 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]
> asterisk(ast_frame_free+0x3d)[0x809c39d]
> /usr/lib/asterisk/modules/app_fgcom.so(member_exec+0x3e4)[0xb66dac54]
> /usr/lib/asterisk/modules/app_fgcom.so[0xb66da049]
> asterisk(pbx_exec+0x6b)[0x80b8c7b]
> asterisk[0x80b9992]
> /usr/lib/asterisk/modules/app_macro.so[0xb649dd50]
> asterisk(pbx_exec+0x6b)[0x80b8c7b]
> asterisk[0x80b9992]
> asterisk[0x80bab15]
> asterisk[0x80bb5ae]
> asterisk[0x80e3ac7]
> /lib/libpthread.so.0[0xb7ee5f50]
> /lib/libc.so.6(clone+0x5e)[0xb7dfd69e]
> ...
> --- cut here ---
>
> Sometimes I geta simple "Segmentation fault"...
>
> 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?
>
> TIA, Holger
> --
> ##### #### ## ## Holger Wirtz Phone : (+49 30) 884299-40
> ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70
> ## ## #### ###### Alexanderplatz 1 E-Mail: wirtz@dfn.de
> ## ## ## ## ### 10178 Berlin
> ##### ## ## ## GERMANY WWW : http://www.dfn.de
> GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
Posted: Sat May 23, 2009 6:38 pm Post subject: [asterisk-dev] How to find crashing problems (cause maybe do
Tilghman,
thanks a lot! This is a great document. I hope I understand using
valgrind - I need to read much more about that.
Regards, Holger
Tilghman Lesher wrote:
Quote:
On Friday 22 May 2009 03:13:09 Holger Wirtz wrote:
> 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