Memory problems when refreshing web page multiple times

[eugeneryabtsev]

I use FSLMQXOS_4_1_2_Vybrid and a Vybrid board. I start RTCS (...blah-blah-blah... _RTCS_socket_part_max = 8 ...blah-blah-blah...), bind interfaces, do HTTPSRV_init (...blah-blah-blah... max_ses = 8 ...blah-blah-blah...), open a web page and start hitting "refresh". After some continuing refreshing, the system starts to have all sorts of problems (ways beyond a simple refusal to continue to serve the pages; a crash beyond the ability to debug it is not uncommon). I see that quite a lot of memory is consumed by TCP sockets that are not quite sockets (see the attachment).

I have two questions with regard to this:

1. Is it only me or there are indeed crash-size problems with hitting an out-of-memory memory condition?

2. How to really limit the memory usage of TCP stack?

3. And a final, theoretical, question: do sockets with no data to send and no handle to send it through and in a "Time Wait" condition have to retain their full Rx/Tx Window buffers?

[PetrK]

Hello Eugene,

I'm facing similar problem, and it's related to the TCPIP event list corruption. In my case the unhandled interrupt was hard fault interrupt and from context stored on the stack it had occured in timer.c in TCPIP_Event_* functions. Unfortunately I haven't traced it down where corruption occurs yet.

Maybe it points you to the right way.

Regards,

Petr

[eugeneryabtsev]

I rather fixed it FOR MY DEBUG PURPOSES by making the following changes:

1. In httpsrv_ses_close:

shutdown(session->sock, FLAG_CLOSE_TX);

_time_delay(100);

shutdown(session->sock, FLAG_ABORT_CONNECTION);

2. In TCP_Send_reset:

mqx_htons(seg->flags,       RST | ( (sizeof(TCP_HEADER)>>2) << DATAOFS_SHIFT ));

mqx_htons(seg->flags,       ACK | FIN | ( (sizeof(TCP_HEADER)>>2) << DATAOFS_SHIFT ));

...

mqx_htonl(seg->ack,         0);

mqx_htonl(seg->ack,         tcb->rcvnxt);

This is all sorts of ugly and incorrect, but at least makes httpsrv work without crashing the system so I can do the UI and am not stuck. If Freescale does not fix this by about mid-summer, I will have to dig deeper into whatever they did there to fix at least the crash. Would you believe if I say I don't want to?

[eugeneryabtsev]

It seems, the crashes were caused by a bug unrelated to out-of-memory issue, so we have two different problems here.

To reproduce the crashes:

1. Unpack a fresh FSLMQXOS_4_1_2_Vybrid.exe

2. Open httpsrv_svf522revb_a5.eww

3. Build, start

4. Open the "polling example" page in the browser

5. See how it runs with no problem

6. Make the following change in poll.html: setTimeout("loop()", 1000 50)

7. Run mktfs.bat, build, start

8. Open the "polling example" page in the browser (refresh the frame to insure it's not cached one-second version)

9. Observe an MQX_UNHANDLED_INTERRUPT in TCP/IP task error code or the crash

(might be related to this)

[alejandrolozan1]

Hi,

Let me reproduce the problem.

Which web browser are you using?

Best Regards,

Alejandro

[eugeneryabtsev]

As for the memory consumption, use Chrome. I think that any browser with a preconnect feature will trigger (Firefox also does), but Chrome is the worst.

As for the crashes, polling at 50 ms intervals should trigger for any browser (tested with Chrome).

If neither of this reproduces, let me know.