LWIP hanging after some time due to memory not freeingWhat REALLY happens when you don't free after malloc?Why is it assumed that send may return with less than requested data transmitted on a blocking socket?How to create binary data packet using union struct?CppUTest: how to pass more data to a specific mock call?Configuring TCP keepalive after acceptPing grows after heavy traffic - LwIP + Freerthos + KeilHandling multiple LwIP connections at the same time using netconnSTM32 FreeRTOS lwIP Heap / Stack / Memory Managementrecv blocking until second packet is sentSTM32 + Lwip, MCU load due to broadcast packet

Bit floating sequence

Why are some hotels asking you to book through Booking.com instead of matching the price at the front desk?

Why are there no wireless switches?

Why can't some airports handle heavy aircraft while others do it easily (same runway length)?

What is the purpose of the rotating plate in front of the lock?

Would a character take damage when surrounded by, but not in, flames?

Owner keeps cutting corners and poaching workers for his other company

Why does low tire pressure decrease fuel economy?

Do you need to burn fuel between gravity assists?

Powers of two are not sums of squares of different integers greater than zero

Why did Tony's Arc Reactor do this?

Complex conjugate and transpose "with respect to a basis"

Why is Sojdlg123aljg a common password?

What is the highest velocity a spacecraft has left Earth?

Infinitely many primes

Can taking my 1-week-old on a 6-7 hours journey in the car lead to medical complications?

indexes are not created on localdb

When was "Cable Select" introduced for IDE devices?

I need to know information from an old German birth certificate

How to restrain your dragon?

Should I tip on the Amtrak train?

Python implementation of atoi

The Green Glass Door, Revisited

More than three domains hosted on the same IP address



LWIP hanging after some time due to memory not freeing


What REALLY happens when you don't free after malloc?Why is it assumed that send may return with less than requested data transmitted on a blocking socket?How to create binary data packet using union struct?CppUTest: how to pass more data to a specific mock call?Configuring TCP keepalive after acceptPing grows after heavy traffic - LwIP + Freerthos + KeilHandling multiple LwIP connections at the same time using netconnSTM32 FreeRTOS lwIP Heap / Stack / Memory Managementrecv blocking until second packet is sentSTM32 + Lwip, MCU load due to broadcast packet






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1















OBS: I'm using a STM32F2 microcontroller, FreeRTOS and lwIP and I'm using the raw API



I have an application in which I'm listening to one PC and connecting to another. Basically everything works fine for a while when I am trying to achieve high throughput, but after about half an hour ... about 80~90k packets received it hangs. It actually varies a little bit where it hangs, but it stopped doing it when I started closing the connection whenever tcp_write returnd err_mem.



Sometimes it hangs in this line:



/* useg should point to last segment on unacked queue */

useg = pcb->unacked;

if (useg != NULL)

for (; useg->next != NULL; useg = useg->next); <------- here




Sometimes when I call tcp_write it returns ERR_MEM and it never returns anything besides after ERR_MEM. This is how I send data, basically I accept a connection, recieve data, store the PCB, do something and then reply to that same PCB:



err_t ret;
ret = tcp_write(g_response[i].pcb, data, len, 1);
if(ret == ERR_OK)
tcp_output(g_response[i].pcb);
else
tcp_close(g_response[i].pcb);


Here is how I setup the socket to listen:



pcb = tcp_new();
tcp_bind(pcb, IP_ADDR_ANY, port);
pcb = tcp_listen(pcb);
pcb->so_options |= SOF_KEEPALIVE; // enable keep-alive
pcb->keep_intvl = 1000; // sends keep-alive every second
tcp_accept(pcb, accept);


And here are my callbacks to sent and rcv



static err_t rcv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) 
if(p == NULL)
return ERR_OK;
else if(err != ERR_OK)
return err;


tcp_recved(pcb, p->len);
// do something

pbuf_free(p);

return ERR_OK;


int sentcounter = 0;
static err_t sent(void *arg, struct tcp_pcb *pcb, uint16_t len)

sentcounter++;
return ERR_OK;


static err_t accept(void *arg, struct tcp_pcb *pcb, err_t err)
int i;
tcp_arg(pcb, NULL);
/* Set up the various callback functions */
tcp_recv(pcb, rcv);
tcp_err(pcb, error);
tcp_sent(pcb, sent);

tcp_accepted(pcb);



The way I send data where I close the pcb whenever there isn ERR_MEM may be strange, but now I have fewer lost packets and it actually got me to exchange up to 90k packets, before that it was failing randomly.



I actually need a high throughput, that's why I'm calling tcp_output instead of letting the tcpip_thread deal with sending the packet. Whenever I let this thread take car of the packet eveything just works, but it's too slow (maybe one packet every 200~300 ms, and by calling tcp_output in the function I got to the point where I'm sending the data sub 10 ms ... I'm also not transfering big amounts of data, so that helps).



Recently I've noticed that the tcpip_thread calls the input function, goes to ipv4_input, goes to memp_free and keeps going but never leaves (I'm actually running a new test right now so later I'll update this question with the callstack to the input before it freezes).



Has somebody done anything similar? Bursts of small packets with high throughput?



EDIT: As promised, here is my call stack




osMutexWait() at cmsis_os.c:681 0x800474c sys_arch_protect() at



sys_arch.c:400 0x80146a6 do_memp_free_pool() at memp.c:415 0x800dca2



memp_free() at memp.c:486 0x800dcf8 tcp_seg_free() at tcp.c:1.336



0x800fb0e tcp_receive() at tcp_in.c:1.162 0x8011712 tcp_process() at



tcp_in.c:877 0x8011048 tcp_input() at tcp_in.c:367 0x8010692



ip4_input() at ip4.c:670 0x800c688 ethernet_input() at ethernet.c:176



0x80142fe tcpip_thread() at tcpip.c:124 0x8006836



pxPortInitialiseStack() at port.c:231 0x8004cd0




Just like @Lundin said, it is a concurrency problem. I should probably try to be more careful with how the functions are called. I'll try to modify my code to work with netconn or socket instead of tcp_pcb, and then measure the speeds I get. I really need high throughput










share|improve this question


























  • PCB in the context of embedded systems means Printed Circuit Board, nothing else, so you might want to rename it. Confused the heck out of me until I realized it probably meant Protocol Control Block here.

    – Lundin
    Mar 28 at 10:12











  • Anyway, this bug smells race conditions. You should start by checking how variables and shared between threads/ISRs. Are there shared ones that aren't protected? You didn't post any code at all containing mutex or similar. Are the tcp functions thread-safe?

    – Lundin
    Mar 28 at 10:12











  • @Lundin I know ... but I've been doing this code for so long that I didn't even notice I was actually using pcb ... in my head it was just tcp_pcb. About your suggestion ... my call stack seems to aggree with you. Any ideas? I'm stil testing a few fixes and after that im rewriting my code

    – morcillo
    Mar 29 at 0:38












  • No I don't have any ideas since you didn't post any code containing race condition protection. If there is no such code, well no wonder...

    – Lundin
    Mar 29 at 7:31

















1















OBS: I'm using a STM32F2 microcontroller, FreeRTOS and lwIP and I'm using the raw API



I have an application in which I'm listening to one PC and connecting to another. Basically everything works fine for a while when I am trying to achieve high throughput, but after about half an hour ... about 80~90k packets received it hangs. It actually varies a little bit where it hangs, but it stopped doing it when I started closing the connection whenever tcp_write returnd err_mem.



Sometimes it hangs in this line:



/* useg should point to last segment on unacked queue */

useg = pcb->unacked;

if (useg != NULL)

for (; useg->next != NULL; useg = useg->next); <------- here




Sometimes when I call tcp_write it returns ERR_MEM and it never returns anything besides after ERR_MEM. This is how I send data, basically I accept a connection, recieve data, store the PCB, do something and then reply to that same PCB:



err_t ret;
ret = tcp_write(g_response[i].pcb, data, len, 1);
if(ret == ERR_OK)
tcp_output(g_response[i].pcb);
else
tcp_close(g_response[i].pcb);


Here is how I setup the socket to listen:



pcb = tcp_new();
tcp_bind(pcb, IP_ADDR_ANY, port);
pcb = tcp_listen(pcb);
pcb->so_options |= SOF_KEEPALIVE; // enable keep-alive
pcb->keep_intvl = 1000; // sends keep-alive every second
tcp_accept(pcb, accept);


And here are my callbacks to sent and rcv



static err_t rcv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) 
if(p == NULL)
return ERR_OK;
else if(err != ERR_OK)
return err;


tcp_recved(pcb, p->len);
// do something

pbuf_free(p);

return ERR_OK;


int sentcounter = 0;
static err_t sent(void *arg, struct tcp_pcb *pcb, uint16_t len)

sentcounter++;
return ERR_OK;


static err_t accept(void *arg, struct tcp_pcb *pcb, err_t err)
int i;
tcp_arg(pcb, NULL);
/* Set up the various callback functions */
tcp_recv(pcb, rcv);
tcp_err(pcb, error);
tcp_sent(pcb, sent);

tcp_accepted(pcb);



The way I send data where I close the pcb whenever there isn ERR_MEM may be strange, but now I have fewer lost packets and it actually got me to exchange up to 90k packets, before that it was failing randomly.



I actually need a high throughput, that's why I'm calling tcp_output instead of letting the tcpip_thread deal with sending the packet. Whenever I let this thread take car of the packet eveything just works, but it's too slow (maybe one packet every 200~300 ms, and by calling tcp_output in the function I got to the point where I'm sending the data sub 10 ms ... I'm also not transfering big amounts of data, so that helps).



Recently I've noticed that the tcpip_thread calls the input function, goes to ipv4_input, goes to memp_free and keeps going but never leaves (I'm actually running a new test right now so later I'll update this question with the callstack to the input before it freezes).



Has somebody done anything similar? Bursts of small packets with high throughput?



EDIT: As promised, here is my call stack




osMutexWait() at cmsis_os.c:681 0x800474c sys_arch_protect() at



sys_arch.c:400 0x80146a6 do_memp_free_pool() at memp.c:415 0x800dca2



memp_free() at memp.c:486 0x800dcf8 tcp_seg_free() at tcp.c:1.336



0x800fb0e tcp_receive() at tcp_in.c:1.162 0x8011712 tcp_process() at



tcp_in.c:877 0x8011048 tcp_input() at tcp_in.c:367 0x8010692



ip4_input() at ip4.c:670 0x800c688 ethernet_input() at ethernet.c:176



0x80142fe tcpip_thread() at tcpip.c:124 0x8006836



pxPortInitialiseStack() at port.c:231 0x8004cd0




Just like @Lundin said, it is a concurrency problem. I should probably try to be more careful with how the functions are called. I'll try to modify my code to work with netconn or socket instead of tcp_pcb, and then measure the speeds I get. I really need high throughput










share|improve this question


























  • PCB in the context of embedded systems means Printed Circuit Board, nothing else, so you might want to rename it. Confused the heck out of me until I realized it probably meant Protocol Control Block here.

    – Lundin
    Mar 28 at 10:12











  • Anyway, this bug smells race conditions. You should start by checking how variables and shared between threads/ISRs. Are there shared ones that aren't protected? You didn't post any code at all containing mutex or similar. Are the tcp functions thread-safe?

    – Lundin
    Mar 28 at 10:12











  • @Lundin I know ... but I've been doing this code for so long that I didn't even notice I was actually using pcb ... in my head it was just tcp_pcb. About your suggestion ... my call stack seems to aggree with you. Any ideas? I'm stil testing a few fixes and after that im rewriting my code

    – morcillo
    Mar 29 at 0:38












  • No I don't have any ideas since you didn't post any code containing race condition protection. If there is no such code, well no wonder...

    – Lundin
    Mar 29 at 7:31













1












1








1








OBS: I'm using a STM32F2 microcontroller, FreeRTOS and lwIP and I'm using the raw API



I have an application in which I'm listening to one PC and connecting to another. Basically everything works fine for a while when I am trying to achieve high throughput, but after about half an hour ... about 80~90k packets received it hangs. It actually varies a little bit where it hangs, but it stopped doing it when I started closing the connection whenever tcp_write returnd err_mem.



Sometimes it hangs in this line:



/* useg should point to last segment on unacked queue */

useg = pcb->unacked;

if (useg != NULL)

for (; useg->next != NULL; useg = useg->next); <------- here




Sometimes when I call tcp_write it returns ERR_MEM and it never returns anything besides after ERR_MEM. This is how I send data, basically I accept a connection, recieve data, store the PCB, do something and then reply to that same PCB:



err_t ret;
ret = tcp_write(g_response[i].pcb, data, len, 1);
if(ret == ERR_OK)
tcp_output(g_response[i].pcb);
else
tcp_close(g_response[i].pcb);


Here is how I setup the socket to listen:



pcb = tcp_new();
tcp_bind(pcb, IP_ADDR_ANY, port);
pcb = tcp_listen(pcb);
pcb->so_options |= SOF_KEEPALIVE; // enable keep-alive
pcb->keep_intvl = 1000; // sends keep-alive every second
tcp_accept(pcb, accept);


And here are my callbacks to sent and rcv



static err_t rcv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) 
if(p == NULL)
return ERR_OK;
else if(err != ERR_OK)
return err;


tcp_recved(pcb, p->len);
// do something

pbuf_free(p);

return ERR_OK;


int sentcounter = 0;
static err_t sent(void *arg, struct tcp_pcb *pcb, uint16_t len)

sentcounter++;
return ERR_OK;


static err_t accept(void *arg, struct tcp_pcb *pcb, err_t err)
int i;
tcp_arg(pcb, NULL);
/* Set up the various callback functions */
tcp_recv(pcb, rcv);
tcp_err(pcb, error);
tcp_sent(pcb, sent);

tcp_accepted(pcb);



The way I send data where I close the pcb whenever there isn ERR_MEM may be strange, but now I have fewer lost packets and it actually got me to exchange up to 90k packets, before that it was failing randomly.



I actually need a high throughput, that's why I'm calling tcp_output instead of letting the tcpip_thread deal with sending the packet. Whenever I let this thread take car of the packet eveything just works, but it's too slow (maybe one packet every 200~300 ms, and by calling tcp_output in the function I got to the point where I'm sending the data sub 10 ms ... I'm also not transfering big amounts of data, so that helps).



Recently I've noticed that the tcpip_thread calls the input function, goes to ipv4_input, goes to memp_free and keeps going but never leaves (I'm actually running a new test right now so later I'll update this question with the callstack to the input before it freezes).



Has somebody done anything similar? Bursts of small packets with high throughput?



EDIT: As promised, here is my call stack




osMutexWait() at cmsis_os.c:681 0x800474c sys_arch_protect() at



sys_arch.c:400 0x80146a6 do_memp_free_pool() at memp.c:415 0x800dca2



memp_free() at memp.c:486 0x800dcf8 tcp_seg_free() at tcp.c:1.336



0x800fb0e tcp_receive() at tcp_in.c:1.162 0x8011712 tcp_process() at



tcp_in.c:877 0x8011048 tcp_input() at tcp_in.c:367 0x8010692



ip4_input() at ip4.c:670 0x800c688 ethernet_input() at ethernet.c:176



0x80142fe tcpip_thread() at tcpip.c:124 0x8006836



pxPortInitialiseStack() at port.c:231 0x8004cd0




Just like @Lundin said, it is a concurrency problem. I should probably try to be more careful with how the functions are called. I'll try to modify my code to work with netconn or socket instead of tcp_pcb, and then measure the speeds I get. I really need high throughput










share|improve this question
















OBS: I'm using a STM32F2 microcontroller, FreeRTOS and lwIP and I'm using the raw API



I have an application in which I'm listening to one PC and connecting to another. Basically everything works fine for a while when I am trying to achieve high throughput, but after about half an hour ... about 80~90k packets received it hangs. It actually varies a little bit where it hangs, but it stopped doing it when I started closing the connection whenever tcp_write returnd err_mem.



Sometimes it hangs in this line:



/* useg should point to last segment on unacked queue */

useg = pcb->unacked;

if (useg != NULL)

for (; useg->next != NULL; useg = useg->next); <------- here




Sometimes when I call tcp_write it returns ERR_MEM and it never returns anything besides after ERR_MEM. This is how I send data, basically I accept a connection, recieve data, store the PCB, do something and then reply to that same PCB:



err_t ret;
ret = tcp_write(g_response[i].pcb, data, len, 1);
if(ret == ERR_OK)
tcp_output(g_response[i].pcb);
else
tcp_close(g_response[i].pcb);


Here is how I setup the socket to listen:



pcb = tcp_new();
tcp_bind(pcb, IP_ADDR_ANY, port);
pcb = tcp_listen(pcb);
pcb->so_options |= SOF_KEEPALIVE; // enable keep-alive
pcb->keep_intvl = 1000; // sends keep-alive every second
tcp_accept(pcb, accept);


And here are my callbacks to sent and rcv



static err_t rcv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) 
if(p == NULL)
return ERR_OK;
else if(err != ERR_OK)
return err;


tcp_recved(pcb, p->len);
// do something

pbuf_free(p);

return ERR_OK;


int sentcounter = 0;
static err_t sent(void *arg, struct tcp_pcb *pcb, uint16_t len)

sentcounter++;
return ERR_OK;


static err_t accept(void *arg, struct tcp_pcb *pcb, err_t err)
int i;
tcp_arg(pcb, NULL);
/* Set up the various callback functions */
tcp_recv(pcb, rcv);
tcp_err(pcb, error);
tcp_sent(pcb, sent);

tcp_accepted(pcb);



The way I send data where I close the pcb whenever there isn ERR_MEM may be strange, but now I have fewer lost packets and it actually got me to exchange up to 90k packets, before that it was failing randomly.



I actually need a high throughput, that's why I'm calling tcp_output instead of letting the tcpip_thread deal with sending the packet. Whenever I let this thread take car of the packet eveything just works, but it's too slow (maybe one packet every 200~300 ms, and by calling tcp_output in the function I got to the point where I'm sending the data sub 10 ms ... I'm also not transfering big amounts of data, so that helps).



Recently I've noticed that the tcpip_thread calls the input function, goes to ipv4_input, goes to memp_free and keeps going but never leaves (I'm actually running a new test right now so later I'll update this question with the callstack to the input before it freezes).



Has somebody done anything similar? Bursts of small packets with high throughput?



EDIT: As promised, here is my call stack




osMutexWait() at cmsis_os.c:681 0x800474c sys_arch_protect() at



sys_arch.c:400 0x80146a6 do_memp_free_pool() at memp.c:415 0x800dca2



memp_free() at memp.c:486 0x800dcf8 tcp_seg_free() at tcp.c:1.336



0x800fb0e tcp_receive() at tcp_in.c:1.162 0x8011712 tcp_process() at



tcp_in.c:877 0x8011048 tcp_input() at tcp_in.c:367 0x8010692



ip4_input() at ip4.c:670 0x800c688 ethernet_input() at ethernet.c:176



0x80142fe tcpip_thread() at tcpip.c:124 0x8006836



pxPortInitialiseStack() at port.c:231 0x8004cd0




Just like @Lundin said, it is a concurrency problem. I should probably try to be more careful with how the functions are called. I'll try to modify my code to work with netconn or socket instead of tcp_pcb, and then measure the speeds I get. I really need high throughput







c stm32 freertos lwip






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 29 at 0:36







morcillo

















asked Mar 28 at 6:33









morcillomorcillo

3574 gold badges14 silver badges41 bronze badges




3574 gold badges14 silver badges41 bronze badges















  • PCB in the context of embedded systems means Printed Circuit Board, nothing else, so you might want to rename it. Confused the heck out of me until I realized it probably meant Protocol Control Block here.

    – Lundin
    Mar 28 at 10:12











  • Anyway, this bug smells race conditions. You should start by checking how variables and shared between threads/ISRs. Are there shared ones that aren't protected? You didn't post any code at all containing mutex or similar. Are the tcp functions thread-safe?

    – Lundin
    Mar 28 at 10:12











  • @Lundin I know ... but I've been doing this code for so long that I didn't even notice I was actually using pcb ... in my head it was just tcp_pcb. About your suggestion ... my call stack seems to aggree with you. Any ideas? I'm stil testing a few fixes and after that im rewriting my code

    – morcillo
    Mar 29 at 0:38












  • No I don't have any ideas since you didn't post any code containing race condition protection. If there is no such code, well no wonder...

    – Lundin
    Mar 29 at 7:31

















  • PCB in the context of embedded systems means Printed Circuit Board, nothing else, so you might want to rename it. Confused the heck out of me until I realized it probably meant Protocol Control Block here.

    – Lundin
    Mar 28 at 10:12











  • Anyway, this bug smells race conditions. You should start by checking how variables and shared between threads/ISRs. Are there shared ones that aren't protected? You didn't post any code at all containing mutex or similar. Are the tcp functions thread-safe?

    – Lundin
    Mar 28 at 10:12











  • @Lundin I know ... but I've been doing this code for so long that I didn't even notice I was actually using pcb ... in my head it was just tcp_pcb. About your suggestion ... my call stack seems to aggree with you. Any ideas? I'm stil testing a few fixes and after that im rewriting my code

    – morcillo
    Mar 29 at 0:38












  • No I don't have any ideas since you didn't post any code containing race condition protection. If there is no such code, well no wonder...

    – Lundin
    Mar 29 at 7:31
















PCB in the context of embedded systems means Printed Circuit Board, nothing else, so you might want to rename it. Confused the heck out of me until I realized it probably meant Protocol Control Block here.

– Lundin
Mar 28 at 10:12





PCB in the context of embedded systems means Printed Circuit Board, nothing else, so you might want to rename it. Confused the heck out of me until I realized it probably meant Protocol Control Block here.

– Lundin
Mar 28 at 10:12













Anyway, this bug smells race conditions. You should start by checking how variables and shared between threads/ISRs. Are there shared ones that aren't protected? You didn't post any code at all containing mutex or similar. Are the tcp functions thread-safe?

– Lundin
Mar 28 at 10:12





Anyway, this bug smells race conditions. You should start by checking how variables and shared between threads/ISRs. Are there shared ones that aren't protected? You didn't post any code at all containing mutex or similar. Are the tcp functions thread-safe?

– Lundin
Mar 28 at 10:12













@Lundin I know ... but I've been doing this code for so long that I didn't even notice I was actually using pcb ... in my head it was just tcp_pcb. About your suggestion ... my call stack seems to aggree with you. Any ideas? I'm stil testing a few fixes and after that im rewriting my code

– morcillo
Mar 29 at 0:38






@Lundin I know ... but I've been doing this code for so long that I didn't even notice I was actually using pcb ... in my head it was just tcp_pcb. About your suggestion ... my call stack seems to aggree with you. Any ideas? I'm stil testing a few fixes and after that im rewriting my code

– morcillo
Mar 29 at 0:38














No I don't have any ideas since you didn't post any code containing race condition protection. If there is no such code, well no wonder...

– Lundin
Mar 29 at 7:31





No I don't have any ideas since you didn't post any code containing race condition protection. If there is no such code, well no wonder...

– Lundin
Mar 29 at 7:31












0






active

oldest

votes










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);














draft saved

draft discarded
















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55391457%2flwip-hanging-after-some-time-due-to-memory-not-freeing%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes




Is this question similar to what you get asked at work? Learn more about asking and sharing private information with your coworkers using Stack Overflow for Teams.







Is this question similar to what you get asked at work? Learn more about asking and sharing private information with your coworkers using Stack Overflow for Teams.




















draft saved

draft discarded















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55391457%2flwip-hanging-after-some-time-due-to-memory-not-freeing%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

SQL error code 1064 with creating Laravel foreign keysForeign key constraints: When to use ON UPDATE and ON DELETEDropping column with foreign key Laravel error: General error: 1025 Error on renameLaravel SQL Can't create tableLaravel Migration foreign key errorLaravel php artisan migrate:refresh giving a syntax errorSQLSTATE[42S01]: Base table or view already exists or Base table or view already exists: 1050 Tableerror in migrating laravel file to xampp serverSyntax error or access violation: 1064:syntax to use near 'unsigned not null, modelName varchar(191) not null, title varchar(191) not nLaravel cannot create new table field in mysqlLaravel 5.7:Last migration creates table but is not registered in the migration table

용인 삼성생명 블루밍스 목차 통계 역대 감독 선수단 응원단 경기장 같이 보기 외부 링크 둘러보기 메뉴samsungblueminx.comeh선수 명단용인 삼성생명 블루밍스용인 삼성생명 블루밍스ehsamsungblueminx.comeheheheh

155 수학 과학 기타 둘러보기 메뉴eh추가해eh문서를 완성해