[Serdev] SER coredump in parse_via.c

Jiang Jinke jiangjinke at gmail.com
Tue May 5 20:36:48 CEST 2009


Thanks for the detail answer.

I check the fix and apply to the pre8 version only to see if it will
fix the problem.
But I found coredump after compiling in CentOS 4.7.

#0  0x009427a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0  0x009427a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00983825 in raise () from /lib/tls/libc.so.6
#2  0x00985289 in abort () from /lib/tls/libc.so.6
#3  0x0808ccad in qm_debug_frag (qm=0x810ba80, f=Variable "f" is not available.
) at mem/q_malloc.c:159
#4  0x0808d2bb in qm_malloc (qm=0x810ba80, size=4,
    file=0x703882
"\211t$\004\211T$\b\213}\020\211<$▒\217▒▒▒\205▒x\v\213u\0249\006\017\217\036▒▒▒\213\203▒▒▒▒\2038▒\017\214▒▒▒▒\213▒▒▒▒▒\213\017

\205▒\017\204\t\001", func=0x703846
"9\006\017\217t▒▒▒\213\213▒▒▒▒\2039▒\017\214▒▒▒▒\213▒▒▒▒▒\213\027\205▒\017\204j\001",
line=58) at

mem/q_malloc.c:382
#5  0x007008ec in new_my_id (url=0x816b6c8 "=^\f\b\004▒\026\b") at my_id.c:96
#6  0x006fe159 in call_gmon_start () from
/usr/local/ngsw/lib/ngsw/modules/mysql.so
#7  0x080a488d in table_version (dbf=0x816b6c8, connection=0xbfefab4c,
table=0x172940) at db/db.c:176
#8  0x0016f455 in domain_db_ver (name=0x0) at domain.c:96
#9  0x0016fe63 in mod_init () at domain_mod.c:140
#10 0x0807cd83 in init_mod (m=0x81407fc) at sr_module.c:474
#11 0x0807cd37 in init_mod (m=0x81408ec) at sr_module.c:471
#12 0x0807cd37 in init_mod (m=0x81409dc) at sr_module.c:471
#13 0x0807cd37 in init_mod (m=0x8140acc) at sr_module.c:471
#14 0x0807cd37 in init_mod (m=0x8140bbc) at sr_module.c:471
#15 0x0807cd37 in init_mod (m=0x8140cac) at sr_module.c:471
#16 0x0807cd37 in init_mod (m=0x8140d9c) at sr_module.c:471
#17 0x0807cd37 in init_mod (m=0x8140e8c) at sr_module.c:471
#18 0x0807cd37 in init_mod (m=0x8140f7c) at sr_module.c:471
#19 0x0807cd37 in init_mod (m=0x814106c) at sr_module.c:471
#20 0x0807cd37 in init_mod (m=0x814115c) at sr_module.c:471
#21 0x0807cd37 in init_mod (m=0x814124c) at sr_module.c:471
#22 0x0805e9e6 in main (argc=3, argv=0xbfefae84) at main.c:1581

by increasing the PKG_MEM_POOL_SIZE to 4M, the coredump problem gone.


btw: using ser-0.9.7+cvs20081106 for a heavy loaded server will have
slow response problem. Not check in detail. I just restore the old one
ser-0.9.7-pre8 used for over a month.

Since the upgrade takes some time to adjust the db struct, will
consider later if still having the same problem.

Regards,
Jinke Jiang

On Fri, May 1, 2009 at 12:28 AM, Andrei Pelinescu-Onciul
<andrei at iptel.org> wrote:
> On Apr 26, 2009 at 18:17, Jiang Jinke <jiangjinke at gmail.com> wrote:
>> My ser had several coredumps, it seems that the ser wanted to send 408
>> timeout response to the caller after invite timeout. I can't reproduce
>> the coredump yet.
>>
>> Below are two backtrace results I attached. It's similar to the one
>> described in http://www.archivum.info/serdev@iptel.org/2005-05/msg00014.html.
>> Didn't see any further progress with that problem. I also did a search
>> on the mailing list,
>> didn't find any bug reports matching my problem.
>
> It looks like a memory corruption problem (somebody writes in some
> already free()'ed memory region, or somebody writes more then it has
> allocated).
>
>>
>> I'm running http://ftp.iptel.org/pub/ser/daily-snapshots/stable/ser-0.9.7-pre8_src_2007-01-26.tar.gz.
>
> It might be related to
> http://git.sip-router.org/cgi-bin/gitweb.cgi?p=ser;a=commit;h=4d1c
> but it could also be a bug in an unrelated module.
>
> If you want to keep using 0.9.x, please try the latest 0.9.7 snapshot
> (http://ftp.iptel.org/pub/ser/daily-snapshots/stable/ser-0.9.7+cvs20080424_src.tar.gz).
> Otherwise upgrade to 2.0.1 (stable), 2.1.0 (stable but there are a few
> modules that do not compile) or sip-router (cutting edge future 3.0).
>
> If you still get coredumps after the upgrade, the only way to go
> forward is to compile ser in debug mode. For 0.9.7 this would be:
> make proper; make mode=debug all and maybe make install mode=debug ...
> The debug mode will add more checks for mallocs, so that a possible
> memory corruption bug will be caught earlier and will also help with gdb
>  (no more variables optimized to registers) at the cost of some speed
> (but if you are not running more than a few thousands calls per second
> it shouldn't be a problem).
>
>
> Andrei
>

<div><br></div>


More information about the Serdev mailing list