Chronological Thread 

< Chronological >      < Thread >

---

I have several problems with sending SCTP traffic (medium throughput).
I'm using sctplib 1.0.5 + glib 1.2.0 crosscompiled with uClibc ppc
I use older version of glib because problems with compilation
of glib 2.14.1 on uClibc ppc.

The problem occurs after about 200 frames on sender side.
There are many symptoms (like segmentation fault or rtx_buffer instance not
set which is most common)

It is very hard to debug because there are different symptoms in different
cases
- when I change something in the code I get another crash.

I thought that the main reason is because of wrong locking.

I have dedicated thread for

sctp_extendedEventLoop(lock,unlock,&sctpMutex);

where:
void lock(void* mutexPtr)
{
pthread_mutex_lock((pthread_mutex_t*)mutexPtr);
}

void unlock(void* mutexPtr)
{
pthread_mutex_unlock((pthread_mutex_t*)mutexPtr);
}

I have also included that small patch provided by Oleg
in se_deliver unreliably.
I use modified set of sctp_callbacks where I also put sctpMutex.
When I use standard sctp_eventLoop + mutexes I got same problems.
I use instanceParameters.maxSendQueue = 0;

Here is the backtrace output from gdb for rtx_buffer problem:

Error Info: 11:51:06.338 - rtx_buffer instance not set !
Program received signal SIGABRT, Aborted.
[Switching to Thread 3076 (LWP 382)]
0x3027f5e8 in __uClibc_syscall () from /lib/libc.so.0
#4 0x30036af0 in error_log1 (error_log_level=1, module_name=0x3004be6c
"reltransfer.c",
line_no=455, log_info=0x3004beec "rtx_buffer instance not set !") at
globals.c:328
#5 0x3003f8a0 in rtx_get_obpa (adIndex=0, totalInFlight=0x10b61368) at
reltransfer.c:455
#6 0x30034128 in fc_check_for_txmit (fc_instance=0x10b61368, oldListLen=1,
doInitialRetransmit=0)
at flowcontrol.c:701
#7 0x30034b74 in fc_send_data_chunk (chunkd=0x10b68b48, destAddressIndex=-1,
lifetime=4294967295,
dontBundle=1, context=0x0) at flowcontrol.c:1012
#8 0x300429dc in se_ulpsend (streamId=1, buffer=0x10b02300 "\001",
byteCount=120, protocolId=3,
destAddressIndex=-1, context=0x0, lifetime=4294967295,
unorderedDelivery=0, dontBundle=1)
at streamengine.c:381
#9 0x3002ca18 in sctp_send_private (associationID=1, streamID=1,
buffer=0x10b02300 "\001",
length=120, protocolId=3, path_id=-1, context=0x0, lifetime=4294967295,
unorderedDelivery=0,
dontBundle=1) at distribution.c:2327
#10 0x1000d9b8 in SCTP_send (associationID=1, streamID=1, buffer=0x10b02300
"\001", length=120,
protocolId=3, path_id=-1, context=0x0, lifetime=4294967295,
unorderedDelivery=0, dontBundle=1)
at sctp_wrapper.c:179

The problem is correlated with duplicated TSNs - after they appear on link it
is going to crash.

Conclusions from other observations:
- oldListenLen is -1 or 0 (probably should never happen)
- problems in sort_tsn function from glib (one of the pointers is 0 which
leads to SEGV)

Maybe someone have got similar problems?
What is your experience with sending traffic with medium/high throughput?

Greetings,

Piotr

---

• [SCTP-Discussion] rtx_buffer instance not set during sending traffic, Piotr Gutkowski, 01/29/2008
  • Re: [SCTP-Discussion] rtx_buffer instance not set during sending traffic, Thomas Dreibholz, 01/30/2008

---

Archive powered by MHonArc 2.6.19+.