On Jan 3, 2008 10:21 AM, Pekka Pessi <[EMAIL PROTECTED]> wrote:
> The UDP socket has run out of buffer space. Manual page for sendmsg() says
>
> ENOBUFS
> The output queue for a network interface was full. This gener-
> ally indicates that the interface has stopped sending, but may
> be caused by transient congestion. (Normally, this does not
> occur in Linux. Packets are just silently dropped when a device
> queue overflows.)
>
> From my recollection of Linux nw code the sentence in parenthesis is
> no longer true.
>
> You can use tport tags TPTAG_UDP_RMEM() and TPTAG_UDP_WMEM() to adjust
> the amount of buffer space. On Linux systems, you should also consider
> adjusting rmem and wmem sysctls.
>
> --Pekka
I'll try fiddling with those, but in the meantime I had changed the
values for TPTAG_THRPSIZE and TPTAG_THRPRQSIZE and it seemed to help.
I haven't had any more of those buffer-related problems, but it is
possible that they have only been postponed, because my application
keeps crashing. I'm still getting SIGSEGVs like the one below:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3076 (LWP 1749)]
0x40246c74 in free () from /lib/libc.so.6
Current language: auto; currently c
(gdb) bt
#0 0x40246c74 in free () from /lib/libc.so.6
#1 0x40246bf4 in free () from /lib/libc.so.6
#2 0x400ccc67 in su_home_unref (home=0xe87b568) at su_alloc.c:673
#3 0x4005c2d9 in msg_destroy (msg=0xe87b568) at msg.c:168
#4 0x40079f91 in incoming_reclaim_queued (rm=0x0, msg=0x0,
u=0xbf3ff97c) at nta.c:4924
#5 0x400895f5 in incoming_mass_destroy (sa=0x8127cd8, q=0xbf3ff97c)
at nta.c:6328
#6 0x40088403 in incoming_timer (sa=0x8127cd8, next=-1908420432) at nta.c:6288
#7 0x400710bf in agent_timer (rm=0x8126790, timer=0x81277a0,
agent=0x8127cd8) at nta.c:747
#8 0x400d74a5 in su_timer_expire (timers=0x8126ae4,
timeout=0xbf3ffab0, now={tv_sec = 3408295612, tv_usec = 540469})
at su_timer.c:533
#9 0x400d8573 in su_base_port_run (self=0x8126ac0) at su_base_port.c:334
#10 0x400d120a in su_root_run (self=0x81274d8) at su_port.h:310
#11 0x400d8e22 in su_pthread_port_clone_main (varg=0xbf5ff8dc) at
su_pthread_port.c:321
#12 0x4014b0ce in pthread_start_thread (arg=0xbf3ffc00) at manager.c:291
(gdb) up
#1 0x40246bf4 in free () from /lib/libc.so.6
(gdb) up
#2 0x400ccc67 in su_home_unref (home=0xe87b568) at su_alloc.c:673
673 su_alloc.c: No such file or directory.
in su_alloc.c
(gdb) p home
$1 = (su_home_t *) 0xe87b568
(gdb) p *home
$2 = {suh_size = 504, suh_blocks = 0x0, suh_lock = 0x0}
(gdb) up
#3 0x4005c2d9 in msg_destroy (msg=0xe87b568) at msg.c:168
168 msg.c: No such file or directory.
in msg.c
(gdb) p *msg
$3 = {m_home = {{suh_size = 504, suh_blocks = 0x0, suh_lock = 0x0}},
m_class = 0x8125808, m_oflags = 2,
m_object = 0xe87b604, m_maxsize = 0, m_size = 370, m_chain =
0xf39f098, m_tail = 0xcb761f8, m_chunk = 0x0, m_buffer = {{
mb_data = 0xf09f120 "p\031,\017ð\234¯\r200 OK\r\nVia:
SIP/2.0/UDP 10.40.0.250:5060;branch=z9hG4bK34849\r\nFrom:
<sip:[EMAIL PROTECTED]>;tag=14391SIPpTag0034849\r\nTo:
<sip:[EMAIL PROTECTED]>;tag=3N12cB7QHHFaN\r\nCall-ID:
34849-1439"..., mb_size = 1024, mb_used = 370, mb_commit = 0, mb_eos =
0, 0}}, m_stream = 0x0, m_ssize = 0, m_extract_err = 0,
m_set_buffer = 0, m_streaming = 0, m_prepared = 1, 0, m_next = 0x0,
m_parent = 0xe87b368, m_refs = 0, m_addrinfo = {
ai_flags = 0, ai_family = 2, ai_socktype = 2, ai_protocol = 17,
ai_addrlen = 16, ai_addr = 0xe87b5e0,
ai_canonname = 0x0, ai_next = 0x0}, m_addr = {{su_dummy = 2, su_family = 2,
su_array = "\002\000\023Ä\n(\000ú", '\000' <repeats 23 times>,
su_array16 = {2, 50195, 10250, 64000,
0 <repeats 12 times>}, su_array32 = {3289579522, 4194314250,
0, 0, 0, 0, 0, 0}, su_sa = {sa_family = 2,
sa_data = "\023Ä\n(\000ú\000\000\000\000\000\000\000"}, su_sin
= {sin_family = 2, sin_port = 50195, sin_addr = {
s_addr = 4194314250}, sin_zero =
"\000\000\000\000\000\000\000"}, su_sin6 = {sin6_family = 2, sin6_port
= 50195,
sin6_flowinfo = 4194314250, sin6_addr = {in6_u = {u6_addr8 =
'\000' <repeats 15 times>, u6_addr16 = {0, 0, 0, 0,
0, 0, 0, 0}, u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id =
0}}}, m_errno = 0}
(gdb)
You've told me before that they are probably related to some memory
overrun. I've ran my application under valgrind and there were no
errors reported for a single call, so I'm guessing it's something
related to concurrency under heavy load. Could you please try to give
me a hint of what I could be doing to overflow the stack's memory
space?
I'm really looking forward for your help. Thanks in advance.
Fabio Margarido
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
