Re: [Sofia-sip-devel] No buffer space available
On Jan 22, 2008 3:27 PM, Pekka Pessi [EMAIL PROTECTED] wrote: There was in deef memory corruption in nta if sending ACK failed.. I push fix to darcs asap. That's great to hear! I've been on vacation and haven't followed the list for a couple of weeks. Is the fix already in darcs? Is it in 1.12.8? Thanks. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] No buffer space available
2008/1/8, Fabio Margarido [EMAIL PROTECTED]: I suspect it is the same issue I described in my other thread (http://sourceforge.net/mailarchive/forum.php?thread_name=1715019e0712120241j71323d0bs6ae65bd9bd60166c%40mail.gmail.comforum_name=sofia-sip-devel), in which Mikhail Zabaluev suggested I used nua_handle_unref(). If I confirm this was indeed the same issue, what should I do? If I understand correctly, the right way is to use nua_handle_destroy(), but it has a known problem, is that it? There was in deef memory corruption in nta if sending ACK failed.. I push fix to darcs asap. -- Pekka.Pessi mail at nokia.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] No buffer space available
2007/12/18, Fabio Margarido [EMAIL PROTECTED]: I'm getting a bunch of these after a large number of calls in my application: tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.9:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 183 Session Progress for INVITE (1)\par 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 -- Pekka.Pessi mail at nokia.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] No buffer space available
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/vse012070mrt/direct/01/
Re: [Sofia-sip-devel] No buffer space available
2008/1/3, Fabio Margarido [EMAIL PROTECTED]: On Jan 3, 2008 11:46 AM, Pekka Pessi [EMAIL PROTECTED] wrote: I have no idea. It seems to be that your problem is because the freelist is corrupted, and it should be possible to detect that with valgrind. Are you using NDEBUG? By default, the stack fills the freed memory with garbage, but if you have NDEBUG defined, it does not. I ran configure with --enable-ndebug, but the funny thing is I didn't see -DNDEBUG in the compilation commands anywhere. There's a detail in my implementation that I a little suspicious about. I have a class that represents a SIP call, and associated with each object of this class is a su_home_t instance. I don't know if that's a bad design decision, but if you feel that might be a problem, it could be changed. The destructor of this class calls su_home_unref for the object's instance of su_home_t. While I'm at it, the whole list of sofia calls my destructor does is, in order: nua_handle_magic, to obtain my context associated to the call, and then free on the pointer returned; And subsequent call to nua_handle_bind(nh, NULL)? nua_handle_unref (it was nua_handle_destroy, but someone on the list suggested I changed it); Please, use nua_handle_destroy(). You may get events after nua_handle_unref() nua_destroy_event (for all the saved events I have on a list in each object); su_home_deinit on the object's memory home. Do you see any problem with this approach? I'm thinking of leaving the su_home_t of each object pointing to NULL instead of using su_home_init in the constructor and see where that goes. Unless you call nua_handle_destroy() you may get events from stack and if you do not call nua_handle_bind(nh, NULL) the stack keeps your stale pointer around and passes it to your callback in events... I send this to list, too.. -- Pekka.Pessi mail at nokia.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
