20 Jul
2005
20 Jul
'05
5:15 p.m.
Hello Dan.
First of all thanks for your help on this issue, as i mentioned
before this problem is getting very complicated to me.
The machine with problems is a "production" machine, so i need to
make the changes in "low load" hours. But even when the update was made the
crashes are presenting every 4 or 5 days so i need to wait a few day to see
is the problem persist.
A few last things.
1.- You mentioned the possibility to be running out of memory. This
is the output from the "free" command
total used free shared buffers cached
Mem: 1030888 993944 36944 0 100892 695612
-/+ buffers/cache: 197440 833448
Swap: 2040244 5188 2035056
According to this i have 833M of free memory (the other memory is
cached and buffered).
2.- I'm downloading SER from CVS with the command :
cvs -z3 -d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser co
-rrel_0_9_0 sip_router
To download the changes you introduce in mediaproxy.c i need to run
the same command ????
3.- How do i compile SER without optimization?
Thanks again!
Best Regards,
Ricardo Martinez.-
-----Mensaje original-----
De: Dan Pascu [mailto:dan@ag-projects.com]
Enviado el: Miércoles, 20 de Julio de 2005 0:49
Para: Ricardo Martinez
CC: 'serdev(a)lists.iptel.org'org'; 'serusers(a)lists.iptel.org'
Asunto: Re: [Serdev] Help needed with core.dumps from SER
On Tuesday 19 July 2005 22:00, Ricardo Martinez wrote:
Hello.
On this same issue. Today i had another crash from my SER. I'm
attaching the gdb output from the core file. Could this
be related to a
glibc issue as Dmitry Semyonov pointed? Hope that
someone
can help me.!
I don't think it has anything to do with glibc. In mediaproxy
there is a place
where a memory allocation is not checked. I noticed this
before asking you
all the info, but I wanted to see all the info I asked for
because I wasn't
sure that was the only issue. I'm not sure about that even
now, because of
the weird pointer value (it's 0x5 not 0x0), but that may be
because ser was
compiled with optimizations and in this case some info is
unreliable in gdb.
Also unless you have very little memory it's highly unlikely
that you run out
of memory.
I'll commit the fix to cvs, but I'm still not sure that this
memory check is
the only issue involved. We can see after that if you still
have issues and
we can trace them further then if needed. After I commit the
fix, if the
problem persists, you may need to compile ser without
optimizations -O0 to
get more reliable information from gdb.
--
Dan