buglwIP - A Lightweight TCP/IP stack - Bugs: bug #36380, unsent_oversize mismatch in...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #36380: unsent_oversize mismatch in 1.4.1RC1

Submitter:  Marco Jakobs <marcoj>
Submitted:  Thu 03 May 2012 12:27:11 PM UTC
   
 
Category:  TCP Severity:  3 - Normal
Item Group:  Crash Error Status:  Fixed
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  Other

Jump to the original submission

Mon 30 Jun 2014 09:57:21 AM UTC, comment #35: 

You can fetch the git commit number 32b1a9fc8a335c4c771023dd8ace9db9fd814ad1 and try to backport the diffset to lwIP 1.4 branch.

Sylvain Rochet <gradator>
Group Member
Mon 30 Jun 2014 09:45:59 AM UTC, comment #34: 

Where can I download patch# 8237 ? I also have problems with logging off and high-load transmission. This is a serious issue, which takes me a lot of time.

Bart Houkes <mensfort>
Wed 16 Apr 2014 11:29:02 AM UTC, comment #33: 

Is this a candidate for update on stable branch ?

Harm Verhagen <harm>
Wed 16 Apr 2014 08:48:18 AM UTC, comment #32: 

Great, thanks.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 16 Apr 2014 08:15:06 AM UTC, comment #31: 

I tried backporting that particular fix 1.4.1 branch.
That seems to solve the problem.


See attached backport to 1.4.1 branch:
0001-patch-8237-by-Brian-Fahs-tcp_rexmit_rto-fails-to-upd.patch




Harm Verhagen <harm>
Mon 14 Apr 2014 09:37:20 AM UTC, comment #30: 

Could you try with git master? We had another bug in this area, which is now fixed and might fix it for you, too (patch# 8237).

Simon Goldschmidt <goldsimon>
Group administrator
Mon 14 Apr 2014 07:59:09 AM UTC, comment #29: 

In the assert I got the variables had the following contents

wip-1.4.1/src/core/tcp_out.c:445 unsent_oversize mismatch (pcb vs. last_unsent) -- assertion failed

pcb->unsent_oversize: 0
last_unsent->oversize_left: 920

Harm Verhagen <harm>
Mon 14 Apr 2014 07:57:16 AM UTC, comment #28: 

I think this ticket should be reopened.

I am still seeing this on 1.4.1


lwip-1.4.1/src/core/tcp_out.c:445 unsent_oversize mismatch (pcb vs. last_unsent) -- assertion failed
2013-01-01T01:13:03.800Z:ERROR:tcp_out.c:445:unsent_oversize mismatch (pcb vs. last_unsent) -- assertion failed

The code does contain the fix for this ticket

(tcp_out.c:483)
        last_unsent->oversize_left += oversize;


version
-------
STABLE-1_4_1

Harm Verhagen <harm>
Tue 08 May 2012 05:43:44 AM UTC, comment #27: 

Fixed in both master and 1.4.1 branches.

Again, this was a debug-check issue only, as long as TCP_OVERSIZE_DBGCHECK was disabled, there was no problem.

Simon Goldschmidt <goldsimon>
Group administrator
Mon 07 May 2012 09:12:08 PM UTC, comment #26: 


>What kind of errors did you see? Asserts? Reboots?


Dropped or not processed packets as I have a few retransmissions at the start of a large transfer (to lwIP).  If this bug report is for asserts only then it is not what I'm seeing.  It could well be that lwIP 1.4.1 is faster and I've made improvements to speed up my driver and application too which now show something that's always been there.  I commented only because I know it was error-free 6-8 months ago and I did update to the lwIP code base head in the interim.

Bill Auerbach <billauerbach>
Mon 07 May 2012 08:46:14 PM UTC, comment #25: 

@Ivan,

would you like to share your improvements to the driver? I'm still digging around as the datasheet is not the best in this world ;-) ... have sent an enquiry to the Atmel support team today ...

You can also contact me on mj at jacotec dot de (this is not the right place to discuss ...)

Marco

Marco Jakobs <marcoj>
Mon 07 May 2012 08:25:45 PM UTC, comment #24: 


> also think there may be something to this post. On my 10/100
> lwIP product I recently ran with WireShark and noticed there
> were errors.


What kind of errors did you see? Asserts? Reboots?

Simon Goldschmidt <goldsimon>
Group administrator
Mon 07 May 2012 08:17:30 PM UTC, comment #23: 

Well, great! I'll push the changes I've made, then.

Thanks for reporting and testing!

Simon Goldschmidt <goldsimon>
Group administrator
Mon 07 May 2012 07:41:33 PM UTC, comment #22: 

Hi Simon,

the Assert seems to be gone with your tcp_out.c ... ran it about 15mins with TCP_OVERSIZE=1 without problems.

Marco Jakobs <marcoj>
Mon 07 May 2012 07:34:28 PM UTC, comment #21: 

Just a sidebar comment, I noticed Marco is using SAM7_EMAC. I've had trouble with some versions of this driver that are shipped with some RTOSes, e.g. FreeRTOS. Seems to happen once things start to move "fast". There are a number of assumptions in those drivers that don't always hold.

Maybe something new is causing things to move a little too fast for the driver?

I've made a number of changes to the SAM7_EMAC driver and things work much better for me now...

Ivan Delamer <idelamer>
Group Member
Mon 07 May 2012 02:13:25 PM UTC, comment #20: 


>My feeling is, that something has changed in 1.4.1 causing bad
>problems as soon as a big amount of data is put out on a TCP
>connection.


I also think there may be something to this post.  On my 10/100 lwIP product I recently ran with WireShark and noticed there were errors.  I know it used to be 100% error free - 10/100 is not very fast.  I debugged my driver thinking something had changed and I was unable to make it error-free.  When I can, I will downgrade lwIP and retest this product.

Bill Auerbach <billauerbach>
Mon 07 May 2012 01:16:02 PM UTC, comment #19: 

Hi Simon,

i'll give it a try tonight and report!

Marco Jakobs <marcoj>
Mon 07 May 2012 11:55:31 AM UTC, comment #18: 

Marco,

After I have reproduced this, it seems like only the debug counter was counted wrong. Can you please check the attached file (tcp_out.c) with 1.4.1 RC1? If it works, I'll check it in.

(file #25812)

Simon Goldschmidt <goldsimon>
Group administrator
Mon 07 May 2012 11:06:05 AM UTC, comment #17: 


> with the worse setting "TCP_OVERSIZE=1" i see the same assert also in 1.4.0.


In that case, I guess this bug is a duplicate to bug #32417 (TCP_OVERSIZE seems to have problems with (fast-)retransmission), which I'm going to reopen when I confirmed this bug, as it means that the fix for that bug was either not enough or invalid.

In any case, you don't risk anything by disabling TCP_OVERSIZE (define it to 0). The TCP_OVERSIZE feature is mainly a performance imrpovement to ensure TCP segments are allocated in a single pbuf. Without this, every call to tcp_write() creates a new pbuf and segments are made up of multiple pbufs unless one call to tcp_write() contains enough data for a single segment. If you had no problems with it being like that in 1.3.2, you can safely turn this new feature off.

Simon Goldschmidt <goldsimon>
Group administrator
Sun 06 May 2012 03:55:12 PM UTC, comment #16: 

Hi Simon,

with the worse setting "TCP_OVERSIZE=1" i see the same assert also in 1.4.0.

Marco Jakobs <marcoj>
Sun 06 May 2012 11:30:23 AM UTC, comment #15: 

I can't comment on the parts you wrote about your hardware or netif driver, as I don't know that one. Also, it seems a bit off topic here given the summary of this bug.

But to sum up the rest: you are having asserts triggering with 1.4.1 RC1 when using TCP_OVERSIZE != 0. Leaving your hardware/driver issues aside, are you having problems with 1.4.0, too? Because there haven't been too many changes in the TCP_OVERSIZE algorithm between these 2 versions.

I'll try to reproduce this with TCP_OVERSIZE = 1 when I find the time, your log output is a very helpful start to do this, thanks for that!

Simon Goldschmidt <goldsimon>
Group administrator
Sat 05 May 2012 06:05:27 PM UTC, comment #14: 

TCP_OVERSIZE = 128

Much worse than TCP_MSS. "unsent_oversize mismatch" assert in average of 5-30 seconds after the TCP transmissions start
No EMAC Tx Errors.


TCP_OVERSIZE = 1
Absolutely worse: "unsent_oversize mismatch" assert immediately after the TCP connestion hast started - and anytime. Good setting for testing / debugging this ;-)
No EMAC Tx Errors.


TCP_OVERSIZE = TCP_MSS: I see EMAC Transmit errors here (buffer underrun, Used Bit Read etc.) in many cases right before the assert happens.


With TCP_OVERSIZE=1 it was easy to get your requested debug output as the system gives the assert immediately:


System up and running ... switching to operating mode.
Ethernet link is up. Own IP:10.1.1.1
05.05.12 20:02:43   **Device started with SW-Version: 02.00**
05.05.12 20:02:43   Restart cause: 00010201
tcp_enqueue_flags: queueing 6509:6510 (0x2)
tcp_output_segment: 6509:6509
tcp_output: nothing to send (00000000)
05.05.12 20:02:43   Internal extension board found.
05.05.12 20:02:43   I/O-Board found with SW-Version: 01.33.
05.05.12 20:02:43   Displayboard found with SW-Version: 01.33.
05.05.12 20:02:53   Device was 0 days, 0 hours, 0 minutes and 24 seconds down!
05.05.12 20:02:53   Ethernet link is up. Own IP:10.1.1.1
05.05.12 20:02:53   Looking for redundancy CPU.
05.05.12 20:02:53   Alarm logger code 0001 to user 1 passed to eMail output.
05.05.12 20:02:53   Found secondary CPU in standby.
05.05.12 20:02:53   RTU #1 'Keller' is online.
05.05.12 20:02:53   Taking control as PRIMARY CPU.
05.05.12 20:02:53   RTU #2 'Erdgeschoss' is online.
05.05.12 20:02:53   RTU #3 'Obergeschoss' is online.
05.05.12 20:02:54   Local Bus: Unknown scancode FF - bus deactivated!
tcp_output: nothing to send (00000000)
tcp_output_segment: 6509:6509
tcp_output: sending ACK for 859912022
tcp_output: nothing to send (00000000)
tcp_write(pcb=0020cc00, data=00218ff4, len=17, apiflags=1)
tcp_write: queueing 6510:6527
tcp_output_segment: 6510:6527
tcp_output: nothing to send (00000000)
tcp_write(pcb=0020cc00, data=00218ff4, len=12, apiflags=1)
tcp_write: queueing 6527:6539
tcp_output_segment: 6527:6539
tcp_output: nothing to send (00000000)
tcp_write(pcb=0020cc00, data=00218ff4, len=14, apiflags=1)
tcp_write: queueing 6539:6553
tcp_output_segment: 6539:6553
tcp_output: nothing to send (00000000)
tcp_write(pcb=0020cc00, data=00218ff4, len=10, apiflags=1)
tcp_write: queueing 6553:6563
tcp_output_segment: 6553:6563
tcp_output: nothing to send (00000000)
tcp_write(pcb=0020cc00, data=00218ff4, len=29, apiflags=1)
tcp_write: queueing 6563:6592
tcp_output_segment: 6563:6592
tcp_output: nothing to send (00000000)
tcp_write(pcb=0020cc00, data=0021a11e, len=26, apiflags=1)
tcp_write: queueing 6592:6618
tcp_output_segment: 6592:6618
tcp_output: nothing to send (00000000)
tcp_write(pcb=0020cc00, data=00218ff4, len=6, apiflags=1)
tcp_write: queueing 6618:6624
tcp_output_segment: 6618:6624
tcp_enqueue_flags: queueing 6516:6517 (0x12)
tcp_output_segment: 6516:6516
tcp_output: nothing to send (00000000)
tcp_output: nothing to send (00000000)
Logger connection established from 10.0.1.1.
tcp_write(pcb=0020cb64, data=0021bac8, len=154, apiflags=1)
tcp_write: queueing 6517:6671
tcp_output_segment: 6517:6671
tcp_write(pcb=0020cb64, data=0021bac8, len=510, apiflags=1)
tcp_write: queueing 6671:7181
tcp_write(pcb=0020cc00, data=00218ff4, len=15, apiflags=1)
tcp_write: queueing 6624:6639
tcp_output_segment: 6624:6639
tcp_write(pcb=0020cc00, data=00218ff4, len=24, apiflags=1)
tcp_write: queueing 6639:6663
tcp_write(pcb=0020cc00, data=00218ff4, len=18, apiflags=1)
tcp_write(pcb=0020cb64, data=0021bac8, len=509, apiflags=1)
tcp_write(pcb=0020cc00, data=0021a11e, len=21, apiflags=1)
ASSERT: C:/Projekte/HCS-CPU2/Libraries/lwIP/src/core/tcp_out.c:445:unsent_oversize mismatch (pcb vs. last_unsent)

Marco Jakobs <marcoj>
Sat 05 May 2012 05:41:59 PM UTC, comment #13: 

Final conclusion after 10h leaving it running with TCP_OVERSIZE = TCP_MSS:

Around 5 asserts per hour:
ASSERT: C:/Projekte/HCS-CPU2/Libraries/lwIP/src/core/tcp_out.c:445:unsent_oversize mismatch (pcb vs. last_unsent)

So, TCP_OVERSIZE=TCP_MSS is somehow not working in my environment. I'll try around with the other suggested values ...

Marco Jakobs <marcoj>
Sat 05 May 2012 10:48:24 AM UTC, comment #12: 

I did some first load tests with the line added below in lEMACSend and the TCP_OVERSIZE set to TCP_MSS.

So far i've seen no assert.

I'll leave it running for a while with this setup, if you see any correlation between my theory below and the initial bug, please feel free to close it. If you want some special tests, let me kmow.

I'd appeciate comments on my post below, also is there a more extensive description of the advantage of the TCP_OVERSIZE set and impact to performance and system load / resources? I want to have a deeper understanding on this.

Again, please apology my bad mood yesterday evenig! ;-)

Marco

Marco Jakobs <marcoj>
Sat 05 May 2012 10:36:00 AM UTC, comment #11: 

Dear Simon,

i've spent a part of the night going through the SAM7_EMAC.c for the transmissions. The number of blocked Tx Buffers pointed me there (There should never be a "lost" buffer if Tx is good).

As you've much more experience, i'd share my thoughts here ...

<THEORY>
The "lEMACSend" function writes the pbuf in the EMAC transmit buffers and then sets the "TSTART" flag of the EMAC to start the transmission. The transmission end is signalled by the ISR, freeing the used EMAC buffers in the desription pointers list.

However, the lEMACSend only checks if the buffer space is full - when the potential buffer for the next write is tagged as "unused" (AT91C_TRANSMIT_OK auf 0) this block is not yet sent - in this case it does some vTaskDelay until the block has been transmitted to continue the writing of the actual pBufs to the EMAC buffers. In case that a timeout occurs here, i'll get the "Buffer blocked" logger output: Then an EMAC buffer tagged for transmission is never transmitted (which should not occur) and all Buffers are reset to prevent a permanent blocked Ethernet transmission.

The thought is: It should normally NEVER come to a "not transmitted" block.

After a pbuf is written, the transmission is started by setting the "TSTART" bit in the EMAC Network Control Register (NCR) and the lEMACSend will be left. If lEMACSend is called the next time, it will write the new pbuf in the next free buffers and set the TSTART again (which is allowed be be done during a still ongoing transmission).

My theory here: If a transmission is ongoing (large packet) and the first (small) pbuf is written, TSTART is set. The EMAC should do this new transmission right after the large one has finished. But if the input from LwIP is so fast that a third (small) packet will be written during the first large one is still in transmission and the second small one is queued (TSTART is still set because of the second packet waiting), the third packet will be written in the buffer, but as the TSTART is still set, this packet will never be transmitted because the EMAC finishes the transmission after packet 2 (the TSTART bit can not count waiting packets as it's just a single flag). As the pointer to the descriptors were not updated, the next packet (number four) will send out packet three (when TSTART is set again by packet four) - however, we have always one "unsent" packet in the EMAC buffers.

Having this behaviour repeated over the time, we may "sum up" some unsent packets until there is no space left on a lEMACSend call - which will free all blocks and trigger the logger message i see.
</THEORY>

I've just added these lines right at the start of lEMACSend:

while (AT91C_BASE_EMAC->EMAC_TSR & AT91C_EMAC_TSTART)
{
  vTaskDelay(1);
}

Which prevents the writing of any new pbuf as long as the TSTART bit is still set (assuming that there is an ongoing transmission AND another block waiting to being transmitted). The AT91SAM7X datasheet unfortunately does not tell me when TSTART will be reset, but i assume this will be happen when the transmission has started. The delay should make sure that no pbuf is written to the EMAC Tx buffers as long as the transmission event can't be told to the EMAC.

With this enhancement i was not able to cause the "Tx Buffers Blocked" error message again and the system seems much more stable on high TCP traffic. I have seem some seldom data aborts putting a high Tx load for a pretty long time.

Changing my delay above to just

while (AT91C_BASE_EMAC->EMAC_TSR & AT91C_EMAC_TSTART);

and was also not able to see this daborts, as i'm now blocking all lower priorities tasks which may continue to feed the LwIP with more data while the (high priority) EMAC task is waiting for the oppertunity to transmit.

Any comments are appreciated here - what is the right way to solve the output problem? How do you this in your proper running project?

I'll test again with the TCP_OVERSIZE set ...


Marco Jakobs <marcoj>
Fri 04 May 2012 09:03:40 PM UTC, comment #10: 

Fr 04 Mai 2012 20:14:17 GMT, Kommentar #9:

>Hey, thanks, it's always nice to hear such constructive criticism! That really motivates me to put effort in lwIP in my free time!


It's not meant that hard as you might understand it ;-)
But it's really a big difference to see how "smooth" the data runs through the logger window with 1.4.0 and how stagnant it is in 1.4.1.

I'm really looking forward to 1.4.1 (i've discovered a send timeout there :-)) ) ... and please: My comment was not very well thought and a subject for being misunderstood. I have to excuse!

Any hint what options i should try to tweak to test would be welcome and i'll do the test again.

>How can that happen? The last failing assert you reported should be deactivated with TCP_OVERSIZE set to 0!


Sorry for that ... i went through the logs again and the assert was from a different source! The system was blocked for a given time in a high priority task (i assume tcpip_thread or EMAC) probably waiting for something ... and a mutex could not be taken in a given time (3 seconds).

Marco Jakobs <marcoj>
Fri 04 May 2012 08:14:17 PM UTC, comment #9: 


>  Gave it another try with TCP_OVERSIZE=0.
>  Absolutely no change,


How can that happen? The last failing assert you reported should be deactivated with TCP_OVERSIZE set to 0!

> in the RC1 version the TCP output is crap and unuseable


Hey, thanks, it's always nice to hear such constructive criticism! That really motivates me to put effort in lwIP in my free time!

Putting this aside, 1.4.1 RC1 runs perfectly well in my environments, so it also might well be a problem in your lwIP port which is has been hidden under pr envious versions. You never know until you actually find the bug.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 May 2012 08:08:56 PM UTC, comment #8: 

Another hint on my testing environment:

I've activated the logger category "Webserver" here in the test. This means that every packet from the Webserver is sent to the browser, but also sent out on the logger connection with some text remarks and message queue info.

So a webserver output TCP packet of MSS will immediately trigger the same size output on the logger TCP connection.

This is what i understand on "high volume output" ;-)

Calling a webserver page with some kilobyte generated output will cause this TCP output twice on two TCP connections. LwIP 1.4.0 can handle this properly, but 1.4.1 fails totally with lots of EMAC Tx (DMA) buffer errors/overruns and finally crahes and the ASSERT output below.

What i notice are also total random data aborts causing watchdog restarts. My call stack output shows me no valueable information here, maybe caused by the use of FreeRTOS. But only in 1.4.1RC1 and the named high volume TCP output.

Marco Jakobs <marcoj>
Fri 04 May 2012 08:01:31 PM UTC, comment #7: 

Gave it another try with TCP_OVERSIZE=0.

Absolutely no change, it crashes after a few seconds on high volume TCP output. 1.4.0 runs smooth here!

Especially my 1.3.x and 1.4.0 settings
#define TCP_SNDLOWAT ((TCP_SND_BUF)/2)
#define TCP_SNDQUEUELOWAT ((TCP_SND_QUEUELEN)/2)

makes it definitely worse!

Sorry to say this, but in the RC1 version the TCP output is crap and unuseable ... needs fixing before a potential release.

Let me know if you need some more tests.

Have a nice WE
Marco

Marco Jakobs <marcoj>
Fri 04 May 2012 07:24:04 AM UTC, comment #6: 

Will try to give it another test on the weekend. Problem is much more easy to trigger at home as my project does more data throughput than the ones at work.

Marco Jakobs <marcoj>
Thu 03 May 2012 07:40:40 PM UTC, comment #5: 

One more thing: does this also happen when setting TCP_OVERSIZE to 0?

Simon Goldschmidt <goldsimon>
Group administrator
Thu 03 May 2012 07:37:12 PM UTC, comment #4: 

Another one:
In my first report, the setting of
#define TCP_SND_BUF 256
if useless, as this is defined in lwipopts.h to 2920 bytes ...

Marco Jakobs <marcoj>
Thu 03 May 2012 07:17:58 PM UTC, comment #3: 

As i think you may ask for, i'll attach my lwipopts.h

(file #25774)

Marco Jakobs <marcoj>
Thu 03 May 2012 07:13:52 PM UTC, comment #2: 

Hi Simon,

i've spent the evening to test it on my private project at home, and the behaviour is the same here. I'm suffering random data aborts in weird places and the described problems as soon as LwIP 1.4.1 is in place.

Unfortunately it won't happen when TCP_OUTPUT_DEBUG is enabled as this is slowing down the system, preventing the problem from happening.

As a conclusion i suspect a timing / overrun error causing this problem. Here are some hints:

I notice that i'm often running into a situation in my EMAC where all Tx Buffers are without a "last block" marking - so i assume that LwIP 1.4.1 writes all available buffers before they can be sent out by the EMAC (using DMA!). I found my EMAC (SAM7_EMAC.c) here in an endless loop, looking for the buffer with the "last buffer" marking as it seems to be overwritten (in vClearEMACTxBuffer).

I'm getting out of that situation now as i'm exiting the while loop in there as soon as the number of rounds exceeds the number of xTxDescriptors (EMAC Tx Buffers). There are 24 of these DMA buffers with a size of 128 Bytes each (3072 bytes in total).

I've also a routine discovering a situation where no empty EMAC buffer is available when data should be written in there. In this case i'm clearing up all the Tx buffers (which may cause the loss of a packet) to get a new start here (otherwise it may lock up in that situation finding no free buffer for starting up). In real live with a huge traffic this happens every few days one time with LwIP 1.3.x or 1.4.0 (i'm getting a logger entry then).

With LwIP 1.4.1 this happens quite every few seconds when my logger is running (my logger puts out all relevant sytem logs, data flow etc. on a TCP connection, so fast output of a huge amount of data). But is does not happen with TCP_OUTPUT_DEBUG enabled which slows down the output. After one or two of these overflows the described ASSERT can be seen.

I've discovered these altered settings in opt.h in 1.4.1:
#define TCP_SND_BUF                     (2 * TCP_MSS)
#define TCP_SNDLOWAT                    LWIP_MIN(LWIP_MAX(((TCP_SND_BUF)/2), (2 * TCP_MSS) + 1), (TCP_SND_BUF) - 1)
#define TCP_SNDQUEUELOWAT               LWIP_MAX(((TCP_SND_QUEUELEN)/2), 5)


Changing these back to the values from 1.3.x and 1.4.0:
#define TCP_SND_BUF                     256
#define TCP_SNDLOWAT                    ((TCP_SND_BUF)/2)
#define TCP_SNDQUEUELOWAT               ((TCP_SND_QUEUELEN)/2)

makes the situation even worse! The system now immediately produces EMAC Tx overflow messages and the named ASSERTs as soon as my logger is connected, causing the TCP data output.

Using the Webserver (ALSO! huge amount of TCP data with fast output) also triggers these problems!

Using "slow" TCP connections like my Telnet console does not make any trouble.


Summary:
My feeling is, that something has changed in 1.4.1 causing bad problems as soon as a big amount of data is put out on a TCP connection. The same output runs smooth and properly in 1.3.x and 1.4.0. One symptom is that 1.4.1 is causing many EMAC buffer overruns, which previous versions does not. Due to small memory i can't exceed the 24x128 Byte EMAC buffers in my system or spend some memory on other places compared to 1.4.0

I hope this helps, unfortunately the debug output slows the system down to not cause the problems, so i can't support you with that. But i'll test any potential fixes of this problem, just report here or contact me on mj at piciorgros.com.

Marco Jakobs <marcoj>
Thu 03 May 2012 04:28:15 PM UTC, comment #1: 

Hmm, we've already had some bugs in that region. However, I would have thought that it got better from 1.4.0 to 1.4.1, not worse :-(

Could you run your test again with TCP_OUTPUT_DEBUG enabled and attach the log file to this bug? That would help a lot!

Simon Goldschmidt <goldsimon>
Group administrator
Thu 03 May 2012 12:27:11 PM UTC, original submission:  

Giving the 1.4.1RC1 a short try i've noticed 2-3 crashes which i've never seen before on LwIP 1.3.x or 1.4.0:

ASSERT: C:/Projekte/DVI-100/Libraries/lwIP/src/core/tcp_out.c:445:unsent_oversize mismatch (pcb vs. last_unsent)

As my code is totally unchanged i just want to report this to give a chance to review this before a misbehaviour will be released in 1.4.1

As i'm having a tight timeline i'm not able to test more at the moment ... also i don't really understand what the error should tell me or what can cause it.

Marco Jakobs <marcoj>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #31179:  0001-patch-8237-by-Brian-Fahs-tcp_rexmit_rto-fails-to-upd.patch added by harm (2KiB - application/octet-stream - backport of patch 8237 to 1.4.1)
file #25812:  tcp_out.c added by goldsimon (51KiB - text/x-csrc)
file #25774:  lwipopts.h added by marcoj (6KiB - text/x-chdr)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gradator (Posted a comment)
  • -email is unavailable- added by mensfort (Posted a comment)
  • -email is unavailable- added by harm (Posted a comment)
  • -email is unavailable- added by idelamer (Posted a comment)
  • -email is unavailable- added by billauerbach (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by marcoj (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-04-16 goldsimon StatusWorks For Me Fixed
        Open/ClosedOpen Closed
    2014-04-16 harm Attached File- Added 0001-patch-8237-by-Brian-Fahs-tcp_rexmit_rto-fails-to-upd.patch, #31179
    2014-04-14 goldsimon StatusFixed Works For Me
        Open/ClosedClosed Open
    2012-05-08 goldsimon StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2012-05-07 goldsimon Attached File- Added tcp_out.c, #25812
        StatusNone Need Info
        Assigned toNone goldsimon
        Planned Release 1.4.1
    2012-05-03 marcoj Attached File- Added lwipopts.h, #25774

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code