TCP/IP stack trapping

[pbreed]

Also what tools revision are you using?
(the contents of the file nburn\release_tag)

[romanluba]

These are the Trap outputs of the s19 files you have provided me, thank you for taking the time to help me debug. The release version I am using is 2.9.2, I will try to re-install the NNDk. Images of the trap are attached.

[pbreed]

Were looking at this... we will get back to you soon...(IE late today early Wedensday)

[pbreed]

Please try the attached...
and send us the full text result of running...

[dciliske]

Just want to pop in and add a bit here. You've got lots of eyeballs on this one since it's quite bizarre what seems to be happening and you see to be able to reproduce it trivially, whereas we cannot.

The status is as follows: the trap is due to a NULL pointer in a buffer member used for read tracking in streams. This NULL pointer is not possible to exist within the code path being affected (aka, the serial port). Therefore, we believe that there is a buffer use-after-free occurring/double-free. This is where the updated executable comes in. The updated image has a build configuration enabled which will trap the application as soon as a buffer is attempted to be freed that is already marked as free. This should cause the application to trap when the buffer is attempted to be freed the second time, which would give insight into the path that triggered it.

Additionally, it would be very beneficial if you can send us a capture of the network traffic to/from the module in the preceding ~60 seconds or since boot, whichever is shorter. If a full capture is not feasible for privacy/data security concerns, a capture of the payloadless V6 headers would also be beneficial. It is recommended that if you can provide these and they may contain sensitive data, the captures should be sent as part of a support (or sales if you do not have a support account) ticket.