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;
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
add a comment |
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
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
add a comment |
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
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
c stm32 freertos lwip
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
add a comment |
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
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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.
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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