{"action":"created","issue":{"url":"https://api.github.com/repos/ARMmbed/mbed-os/issues/6262","repository_url":"https://api.github.com/repos/ARMmbed/mbed-os","labels_url":"https://api.github.com/repos/ARMmbed/mbed-os/issues/6262/labels{/name}","comments_url":"https://api.github.com/repos/ARMmbed/mbed-os/issues/6262/comments","events_url":"https://api.github.com/repos/ARMmbed/mbed-os/issues/6262/events","html_url":"https://github.com/ARMmbed/mbed-os/issues/6262","id":302111421,"number":6262,"title":"LWIP stack corruption - c++x11","user":{"login":"pauluap","id":573966,"avatar_url":"https://avatars3.githubusercontent.com/u/573966?v=4","gravatar_id":"","url":"https://api.github.com/users/pauluap","html_url":"https://github.com/pauluap","followers_url":"https://api.github.com/users/pauluap/followers","following_url":"https://api.github.com/users/pauluap/following{/other_user}","gists_url":"https://api.github.com/users/pauluap/gists{/gist_id}","starred_url":"https://api.github.com/users/pauluap/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pauluap/subscriptions","organizations_url":"https://api.github.com/users/pauluap/orgs","repos_url":"https://api.github.com/users/pauluap/repos","events_url":"https://api.github.com/users/pauluap/events{/privacy}","received_events_url":"https://api.github.com/users/pauluap/received_events","type":"User","site_admin":false},"labels":[{"id":515345275,"url":"https://api.github.com/repos/ARMmbed/mbed-os/labels/component:%20networking","name":"component: networking","color":"5319e7","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":75,"created_at":"2018-03-04T19:00:42Z","updated_at":"2018-03-08T12:41:40Z","closed_at":null,"author_association":"NONE","body":"Target: DISCO_F769NI\r\nToolchain: GCC_ARM 6.3.1 20170215\r\n\r\nThe background is that I'm working on an application that has a Modbus server component.  I'm using modpoll (http://www.modbusdriver.com/modpoll.html) with the command \r\n`modpoll <ip-address> -r 1 -c 72 -t 4:hex -l 0` to perform torture testing.  I had been finding out that the connection fails, then the device isn't responsive anymore, sometimes not even to ping requests.\r\n\r\nI managed to create a working minimal example at https://github.com/pauluap/mbed-os/tree/lwip_cx11_issue\r\n\r\nThe twist is that the issue doesn't appear when building with the `-std=gnuc++98` (with the command `mbed compile -m DISCO_F769NI -t GCC_ARM`) but exhibits problems when building with the `-std=c++11` option (I did this by running `mbed export -i GCC_ARM -m DISCO_F769NI` and then changing the two instances of `-std=gnu++98` in the generated Makefile)\r\n\r\nI ended up getting my hands on a logic analyzer. After attaching a logic analyzer, it seems that there may be multiple issues within this problem.\r\n\r\nI'm attaching saleae logic analyzer captures as well as wireshark captures.  You're more than welcome to download saleae Logic (www.saleae.com/downloads) and Wireshark to open and view the captures.\r\n[capture_fail_201803041016.zip](https://github.com/ARMmbed/mbed-os/files/1778800/capture_fail_201803041016.zip)\r\n\r\nOne aspect of the  problem seems to be that the transmit half of TCP stops working.\r\n![completecapture](https://user-images.githubusercontent.com/573966/36948982-4a7dd27e-1f97-11e8-8d96-4fa0ea04c495.png)\r\nIn the complete capture screenshot above, it can  be observed that the first attach signal leads to a period of more or less normal communication (the solidish gray bars), and then something happens.  The client tries a few retries, closes the socket, and tries reopening the socket (after the solidish gray bars, there's spikes without accompanying spike in the Attach signal, that's the retry, then the Attach spikes represent the client closing and trying to reopen the socket).\r\n\r\n![singlenormalframe](https://user-images.githubusercontent.com/573966/36949054-1759962a-1f98-11e8-980d-76a0baf4c7ca.png)\r\nThis is a capture of a single normal frame.\r\nThe client kicker is the ISR signal which transfers handling out of the ISR context onto the event queue context (indicated by the Pending signal raise).  The pending event is then handled, receiving a frame. The received frame is then \"processed\" (the dummy implementation only sets enough to generate a valid response then pushes a new event onto the event queue) and then finally transmitted.  The socket op communications at the bottom are debug messages reporting on all calls of `socket.recv` and `socket.send`.  In this particular screenshot, the communications are (from left to right)\r\n `8 = recv(&[0], 8)`\r\n`4 = recv(&[8], 4)`\r\n`-3001 = recv(&[0], 8)`\r\n`-3001 = recv(&[0], 8)`\r\n`153 = send(&[0], 153)`\r\n\r\nAnd the cycle is supposed to repeat ad infinitum.  And it does for the gnu++98 build.\r\n\r\nIn the C++11 build though, things fall off the cliff.\r\n![endofnormalcommunications](https://user-images.githubusercontent.com/573966/36949130-17b9eb96-1f99-11e8-82fd-bdbe2b550b75.png)\r\n  The last socket operation here is a `153 = send(&[0], 153)` and then silence.\r\n\r\n![failcommsrestart](https://user-images.githubusercontent.com/573966/36949159-5f2c8b00-1f99-11e8-9777-b47a09d8e7bf.png)\r\nIf I observe a retry, it seems that the incoming frame was captured, processed, and transmitted.  However, it doesn't appear that the client ever received the transmission thus declares a timeout failures and retries.  After a while, the client decides that it's a socket failure, closes the socket and tries to reopen the socket and continue communications.  The same thing as the screenshot above happens, but with the addition of the Attach signal.\r\n\r\nSo, the issue seem to tie in with C++11.  Why is there even a problem?  The LWIP sources are all in C, correct?  And that's still built using -std=gnu99\r\n\r\nI've been working on developing my codebase all throughout this and other issues, and have a pretty extensive C++11 codebase that I would really love to preserve (aside from having to return to the bad old days of C++98), so I'm willing to help in getting to the bottom of this issue.  As you can see, I have a logic analyzer that can assist.  The changing data in the Modbus response is worrying though, pointing to some kind of memory address assignment issue within the GCC_ARM toolchain.\r\n\r\n \r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/ARMmbed/mbed-os/issues/comments/371475976","html_url":"https://github.com/ARMmbed/mbed-os/issues/6262#issuecomment-371475976","issue_url":"https://api.github.com/repos/ARMmbed/mbed-os/issues/6262","id":371475976,"user":{"login":"pauluap","id":573966,"avatar_url":"https://avatars3.githubusercontent.com/u/573966?v=4","gravatar_id":"","url":"https://api.github.com/users/pauluap","html_url":"https://github.com/pauluap","followers_url":"https://api.github.com/users/pauluap/followers","following_url":"https://api.github.com/users/pauluap/following{/other_user}","gists_url":"https://api.github.com/users/pauluap/gists{/gist_id}","starred_url":"https://api.github.com/users/pauluap/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pauluap/subscriptions","organizations_url":"https://api.github.com/users/pauluap/orgs","repos_url":"https://api.github.com/users/pauluap/repos","events_url":"https://api.github.com/users/pauluap/events{/privacy}","received_events_url":"https://api.github.com/users/pauluap/received_events","type":"User","site_admin":false},"created_at":"2018-03-08T12:41:40Z","updated_at":"2018-03-08T12:41:40Z","author_association":"NONE","body":"unnggghhh.  I found a STM32Cube v1.9 package.  It has a LWIP rtos socket server example.  It does seem that mbed based its emac code on a version of the STM32Cube package.  Seems that we've run out of new information, so maybe I'll get some sleep and then try to port v1.9 to mbed when I feel more refreshed and alert.  I think I recall an announcement where the HAL stuff were updated from upstream, not sure if the same was done to the emac code."}}
{"actor":{"display_login":"pauluap"}}