Jon Shallow

I have seen something similar to this which has been fixed. It was something to do with a buffer end definition not getting updated, but am struggling to find what...

I suggest running your code using `valgrind` to track down the memory corruption (the token in the second packet appears to be corrupted).

For the 2.31 sent back from the server acknowledging block 0, is there any data with that? It would be good to look at that response. Can you please make...

That looks fine. A bit puzzled why your client elects to go for a block size of 512 instead of 1024, but am guessing that is because you are telling...

What is your host environment? I am assuming not LwIP or Contiki Does it have a funny size for int? Does it support realloc() ? `coap_add_data_after()` may be returning a...

If you could enable logging at level 7 and then attach the whole trace for the client, then that may help me to see what is happening.

I think this is the area of issue. Please try this change (reverting out the previous one) ```` diff --git a/src/pdu.c b/src/pdu.c index 8a600db..f5f45d5 100644 --- a/src/pdu.c +++ b/src/pdu.c @@...

The "destoyed" options are also 9 bytes long, so my suspicion is that something has overwritten this data with 0s. Replacing these 9 bytes from the genuine pdu with 0s...

So, the corruption is taking place in coap_add_data_after(), and we need to narrow down the issue area. Can you please try ```` diff --git a/src/pdu.c b/src/pdu.c index 8a600db..06fc2ef 100644 ---...

So it really is looking like the realloc() is failing. I would expect your replacement function for realloc() to be tracking the current size of the allocated chunk of heap...