Chronological Thread 

< Chronological >      < Thread >

---

Hi,

The scenario was as follows:

I written two applications: one operating as a server, another - as a client.
Client sends to
server messages of the size and number specified in the command line.
Messages are sent
in the "bundling enabled" mode. I observed two bugs in behaviour:
1) When messages are of the size 40 bytes or less I have a reference to
memory that
has been free(). The reason of this bug I already mentioned.
2) When messages are of the size > 3*1400 = 4200 bytes I observe the
conversation
starts and stops after 6 chunks was sent. I had no time yet to investigate
the reason.
Visually, no more chunks are sent and the server sends to client a packet
time from time.
I used the same diagnostic output [measurementTimerRunOffFunction()] as in
the application localcom.c and my own diagnostics marked with "***" that
shows how many
packets have been sent and received during 1 last second. The traces are as
foolows:

>testClien -s 192.168.0.14 -d 192.168.0.1 -n 100 -l 4201
We are using sctplib version (19) maj=0, min=19
*** Sent 6, Received 6 packets
1 0 0 0 397 17 4416 4096
1 0 0 0 397 17 4416 4096
*** Sent 1, Received 1 packets
1 0 0 0 397 17 1468 2936
1 0 0 0 397 17 1468 2936
. . . . . . . . . . .
1 0 0 0 397 17 1468 2936
1 0 0 0 397 17 1468 2936
*** Sent 1, Received 1 packets
1 0 0 0 397 17 1468 2936
1 0 0 0 397 17 1468 2936
. . . . . . . . . . .
1 0 0 0 397 17 1468 2936
......

----------------------------------------------------------------------------------

>testServer -s 192.168.0.1
We are using sctplib version (19) maj=0, min=19
*** Sent 3, Received 4 packets
1 0 0 4096 0 0 3000 4096
*** Sent 3, Received 2 packets
1 0 0 4096 0 0 3000 4096
*** Sent 1, Received 1 packets
1 0 0 4096 0 0 3000 4096
1 0 0 4096 0 0 3000 4096
. . . . . . . . . . . . . . .
1 0 0 4096 0 0 3000 4096
1 0 0 4096 0 0 3000 4096
*** Sent 1, Received 1 packets
1 0 0 4096 0 0 3000 4096
1 0 0 4096 0 0 3000 4096
. . . . . . . . . . . . . . .

Best regards,
Michael


----- Original Message -----
From: "Andreas Jungmaier"
<ajung AT exp-math.uni-essen.de>
To: "Michael Nikolaev"
<mvn AT gu.kiev.ua>;

<discussion AT sctp.de>
Sent: Friday, August 30, 2002 5:43 PM
Subject: Re: [SCTP-Discussion] Bug in SACK processing


> Michael,
>
> thanks for the input. I will check that.
>
> The idea of having the same chunk pointers in two different
> lists _IS_ good (provided the C-modules that administrate
> these two lists have a clear interface for modifications
> of the chunk data, i.e. the mentioned free() operation).
>
> Can you give us a reproducible scenario that triggers
> the bug you mention ?
>
> Best regards,
> Andreas
>
> On 30 Aug 2002 02:58 CEST you wrote:
>
> > Hello,
> >
> > I guess, there is the following bug in the function rtx_process_sack()
> > [reltransfer.c].
> > At the beginning of this function the function rtx_process_sack() is
> > called that will
> > FREE() chunk data. Afterwards, at the end of rtx_process_sack() one of
> > functions
> > fc_sack_info() or fc_fast_retransmission() will be called that will call
> > eventually
> > fc_dequeue_sacked_chunks(). The latter function is scanning fields of
> > chunk
> > data that have been previously deleted (from heap) in rtx_dequeue_up_to().
> > I think, it is was not very good idea to have the same chunk pointers in
> > two
> > different lists.
> > Best regards,
> > Michael
>
>

---

• [SCTP-Discussion] Bug in SACK processing, Michael Nikolaev, 08/30/2002
  • <Possible follow-up(s)>
  • Re: [SCTP-Discussion] Bug in SACK processing, Andreas Jungmaier, 08/30/2002
    • Re: [SCTP-Discussion] Bug in SACK processing, Michael Nikolaev, 08/30/2002

---

Archive powered by MHonArc 2.6.19+.