search

ARMmbed / mbed-client-quickstart

DEPRECATED: Mbed Client example program.
https://cloud.mbed.com/docs/current
Other
16 stars 15 forks source link

Can't POST callbacks #51

Closed bridadan closed 8 years ago

bridadan commented 8 years ago

If you clone this example and run it, POSTing to run a callback on the device will cause the device to freeze/hang.

This was working recently with a different set of dependencies.

Broken version yotta ls output:

mbed-client-examples 1.1.0
\_ mbed-client 1.4.7
  |_ mbed-client-c 2.2.9 yotta_modules\mbed-client-c
  | \_ nanostack-libservice 3.1.1 yotta_modules\nanostack-libservice
  |_ mbed-client-mbed-os 1.1.6 yotta_modules\mbed-client-mbed-os
  | |_ mbed-drivers 1.2.0 yotta_modules\mbed-drivers
  | | |_ mbed-hal 1.2.2 yotta_modules\mbed-hal
  | | | \_ mbed-hal-freescale 1.0.0 yotta_modules\mbed-hal-freescale
  | | |   \_ mbed-hal-ksdk-mcu 1.0.9 yotta_modules\mbed-hal-ksdk-mcu
  | | |     |_ uvisor-lib 1.0.13 yotta_modules\uvisor-lib
  | | |     \_ mbed-hal-k64f 1.1.0 yotta_modules\mbed-hal-k64f
  | | |       \_ mbed-hal-frdm-k64f 1.0.2 yotta_modules\mbed-hal-frdm-k64f
  | | |_ cmsis-core 1.1.2 yotta_modules\cmsis-core
  | | | \_ cmsis-core-freescale 1.0.0 yotta_modules\cmsis-core-freescale
  | | |   \_ cmsis-core-k64f 1.0.0 yotta_modules\cmsis-core-k64f
  | | |_ ualloc 1.1.0 yotta_modules\ualloc
  | | | \_ dlmalloc 1.0.0 yotta_modules\dlmalloc
  | | |_ minar 1.0.4 yotta_modules\minar
  | | | \_ minar-platform 1.0.0 yotta_modules\minar-platform
  | | |   \_ minar-platform-mbed 1.1.2 yotta_modules\minar-platform-mbed
  | | |_ core-util 1.5.4 yotta_modules\core-util
  | | |_ compiler-polyfill 1.2.1 yotta_modules\compiler-polyfill
  | | \_ greentea-client 0.1.6 yotta_modules\greentea-client
  | \_ sockets 1.1.3 yotta_modules\sockets
  |   \_ sal 1.1.5 yotta_modules\sal
  |     |_ sal-stack-lwip 1.3.0 yotta_modules\sal-stack-lwip
  |     | |_ sal-driver-lwip-k64f-eth 1.0.5 yotta_modules\sal-driver-lwip-k64f-eth
  |     | \_ sal-iface-eth 1.0.1 yotta_modules\sal-iface-eth
  |     \_ unity 2.1.0 yotta_modules\unity
  |       \_ utest 1.10.0 yotta_modules\utest
  \_ mbed-client-mbedtls 1.0.15 yotta_modules\mbed-client-mbedtls
    \_ mbedtls 2.2.0 yotta_modules\mbedtls

Working version yotta ls output:

mbed-client-examples 1.1.0
┗━ mbed-client 1.4.2
  ┣━ mbed-client-c 2.2.7 yotta_modules/mbed-client-c
  ┃ ┗━ nanostack-libservice 3.0.10 yotta_modules/nanostack-libservice
  ┣━ mbed-client-mbed-os 1.1.4 yotta_modules/mbed-client-mbed-os
  ┃ ┣━ mbed-drivers 0.12.1 yotta_modules/mbed-drivers
  ┃ ┃ ┣━ mbed-hal 1.2.2 yotta_modules/mbed-hal
  ┃ ┃ ┃ ┗━ mbed-hal-freescale 1.0.0 yotta_modules/mbed-hal-freescale
  ┃ ┃ ┃   ┗━ mbed-hal-ksdk-mcu 1.0.8 yotta_modules/mbed-hal-ksdk-mcu
  ┃ ┃ ┃     ┣━ uvisor-lib 1.0.12 yotta_modules/uvisor-lib
  ┃ ┃ ┃     ┗━ mbed-hal-k64f 1.1.0 yotta_modules/mbed-hal-k64f
  ┃ ┃ ┃       ┗━ mbed-hal-frdm-k64f 1.0.2 yotta_modules/mbed-hal-frdm-k64f
  ┃ ┃ ┣━ cmsis-core 1.1.2 yotta_modules/cmsis-core
  ┃ ┃ ┃ ┗━ cmsis-core-freescale 1.0.0 yotta_modules/cmsis-core-freescale
  ┃ ┃ ┃   ┗━ cmsis-core-k64f 1.0.0 yotta_modules/cmsis-core-k64f
  ┃ ┃ ┣━ ualloc 1.0.3 yotta_modules/ualloc
  ┃ ┃ ┃ ┗━ dlmalloc 1.0.0 yotta_modules/dlmalloc
  ┃ ┃ ┣━ minar 1.0.4 yotta_modules/minar
  ┃ ┃ ┃ ┗━ minar-platform 1.0.0 yotta_modules/minar-platform
  ┃ ┃ ┃   ┗━ minar-platform-mbed 1.1.2 yotta_modules/minar-platform-mbed
  ┃ ┃ ┣━ core-util 1.3.0 yotta_modules/core-util
  ┃ ┃ ┗━ compiler-polyfill 1.2.1 yotta_modules/compiler-polyfill
  ┃ ┗━ sockets 1.1.1 yotta_modules/sockets
  ┃   ┗━ sal 1.1.3 yotta_modules/sal
  ┃     ┗━ sal-stack-lwip 1.2.0 yotta_modules/sal-stack-lwip
  ┃       ┣━ sal-driver-lwip-k64f-eth 1.0.3 yotta_modules/sal-driver-lwip-k64f-eth
  ┃       ┗━ sal-iface-eth 1.0.1 yotta_modules/sal-iface-eth
  ┗━ mbed-client-mbedtls 1.0.14 yotta_modules/mbed-client-mbedtls
    ┗━ mbedtls 2.2.0 yotta_modules/mbedtls

Looks like this is an issue with the underlying client libraries?

cc @yogpan01

ciarmcom commented 8 years ago

ARM Internal Ref: IOTCLT-609

anttiylitokola commented 8 years ago

Hi, I wasn't able to reproduce this issue with the latest versions. I was able to post to a resource and see the led was blinking based on the pattern.

Here are the versions from my setup: mbed-client-examples 1.1.0 ┗━ mbed-client 1.4.7 ┣━ mbed-client-c 2.2.9 yotta_modules/mbed-client-c ┃ ┗━ nanostack-libservice 3.1.1 yotta_modules/nanostack-libservice ┣━ mbed-client-mbed-os 1.1.6 yotta_modules/mbed-client-mbed-os ┃ ┣━ mbed-drivers 1.2.0 yotta_modules/mbed-drivers ┃ ┃ ┣━ mbed-hal 1.2.2 yotta_modules/mbed-hal ┃ ┃ ┃ ┗━ mbed-hal-freescale 1.0.0 yotta_modules/mbed-hal-freescale ┃ ┃ ┃ ┗━ mbed-hal-ksdk-mcu 1.0.9 yotta_modules/mbed-hal-ksdk-mcu ┃ ┃ ┃ ┣━ uvisor-lib 1.0.13 yotta_modules/uvisor-lib ┃ ┃ ┃ ┗━ mbed-hal-k64f 1.1.0 yotta_modules/mbed-hal-k64f ┃ ┃ ┃ ┗━ mbed-hal-frdm-k64f 1.0.2 yotta_modules/mbed-hal-frdm-k64f ┃ ┃ ┣━ cmsis-core 1.1.2 yotta_modules/cmsis-core ┃ ┃ ┃ ┗━ cmsis-core-freescale 1.0.0 yotta_modules/cmsis-core-freescale ┃ ┃ ┃ ┗━ cmsis-core-k64f 1.0.0 yotta_modules/cmsis-core-k64f ┃ ┃ ┣━ ualloc 1.1.0 yotta_modules/ualloc ┃ ┃ ┃ ┗━ dlmalloc 1.0.0 yotta_modules/dlmalloc ┃ ┃ ┣━ minar 1.0.4 yotta_modules/minar ┃ ┃ ┃ ┗━ minar-platform 1.0.0 yotta_modules/minar-platform ┃ ┃ ┃ ┗━ minar-platform-mbed 1.1.2 yotta_modules/minar-platform-mbed ┃ ┃ ┣━ core-util 1.5.4 yotta_modules/core-util ┃ ┃ ┣━ compiler-polyfill 1.2.1 yotta_modules/compiler-polyfill ┃ ┃ ┗━ greentea-client 0.1.6 yotta_modules/greentea-client ┃ ┗━ sockets 1.1.3 yotta_modules/sockets ┃ ┗━ sal 1.1.5 yotta_modules/sal ┃ ┣━ sal-stack-lwip 1.3.0 yotta_modules/sal-stack-lwip ┃ ┃ ┣━ sal-driver-lwip-k64f-eth 1.0.5 yotta_modules/sal-driver-lwip-k64f-eth ┃ ┃ ┗━ sal-iface-eth 1.0.1 yotta_modules/sal-iface-eth ┃ ┗━ unity 2.1.0 yotta_modules/unity ┃ ┗━ utest 1.10.0 yotta_modules/utest ┗━ mbed-client-mbedtls 1.0.15 yotta_modules/mbed-client-mbedtls ┗━ mbedtls 2.2.0 yotta_modules/mbedtls

Could you try to update versions and then try again?

bridadan commented 8 years ago

I just ran yotta update and I'm still seeing the same problem. I do a POST to the device and then the device becomes unresponsive. I'm getting a 410 "Gone" error in my web app if I make a request to the button resource after the device has become unresponsive.

I've made test REST call with cURL and with this library: https://github.com/ARMmbed/mbed-connector-api-node. Both froze the device.

Here is my yotta ls:

mbed-client-examples 1.1.0
\_ mbed-client 1.4.8
  |_ mbed-client-c 2.2.9 yotta_modules\mbed-client-c
  | \_ nanostack-libservice 3.1.1 yotta_modules\nanostack-libservice
  |_ mbed-client-mbed-os 1.1.6 yotta_modules\mbed-client-mbed-os
  | |_ mbed-drivers 1.3.0 yotta_modules\mbed-drivers
  | | |_ mbed-hal 1.2.2 yotta_modules\mbed-hal
  | | | \_ mbed-hal-freescale 1.0.0 yotta_modules\mbed-hal-freescale
  | | |   \_ mbed-hal-ksdk-mcu 1.0.9 yotta_modules\mbed-hal-ksdk-mcu
  | | |     |_ uvisor-lib 1.0.13 yotta_modules\uvisor-lib
  | | |     \_ mbed-hal-k64f 1.1.0 yotta_modules\mbed-hal-k64f
  | | |       \_ mbed-hal-frdm-k64f 1.0.2 yotta_modules\mbed-hal-frdm-k64f
  | | |_ cmsis-core 1.1.2 yotta_modules\cmsis-core
  | | | \_ cmsis-core-freescale 1.0.0 yotta_modules\cmsis-core-freescale
  | | |   \_ cmsis-core-k64f 1.0.0 yotta_modules\cmsis-core-k64f
  | | |_ ualloc 1.1.0 yotta_modules\ualloc
  | | | \_ dlmalloc 1.0.0 yotta_modules\dlmalloc
  | | |_ minar 1.1.0 yotta_modules\minar
  | | | \_ minar-platform 1.0.0 yotta_modules\minar-platform
  | | |   \_ minar-platform-mbed 1.1.3 yotta_modules\minar-platform-mbed
  | | |_ core-util 1.6.0 yotta_modules\core-util
  | | |_ compiler-polyfill 1.2.1 yotta_modules\compiler-polyfill
  | | \_ greentea-client 0.1.7 yotta_modules\greentea-client
  | \_ sockets 1.1.3 yotta_modules\sockets
  |   \_ sal 1.1.5 yotta_modules\sal
  |     |_ sal-stack-lwip 1.3.0 yotta_modules\sal-stack-lwip
  |     | |_ sal-driver-lwip-k64f-eth 1.0.6 yotta_modules\sal-driver-lwip-k64f-eth
  |     | \_ sal-iface-eth 1.0.1 yotta_modules\sal-iface-eth
  |     \_ unity 2.1.0 yotta_modules\unity
  |       \_ utest 1.10.0 yotta_modules\utest
  \_ mbed-client-mbedtls 1.0.15 yotta_modules\mbed-client-mbedtls
    \_ mbedtls 2.2.0 yotta_modules\mbedtls
yogpan01 commented 8 years ago

Hi, We checked with the node-connector and python web apps and both of them doesn't work when the device goes online. They seems to hang forever. When we try to use REST API calls to the device through CURL or some other REST API tools , the requests are going to device and device is responding back as well. As for the POST request to the Resource level, the content format has to be "plain/text" as this has been mentioned in the specification, otherwise client will respond back with Error Response of "Unsupported Content Format".

bridadan commented 8 years ago

I've pushed a potential fix for the hanging issue that you mentioned @yogpan01 for the Node app, feel free to try that.

I've tried adding the "text/plain" Content-type header to my POST call and that does not fix my issue. The device still crashes.

Maybe we should take this offline and attempt to debug this together? I could get you a binary from my environment so maybe we can track this issue down.

BlackstoneEngineering commented 8 years ago

@yogpan01 Something has changed in the last 2 weeks on this example on the device side. I have a binary from 2 weeks ago and it works just fine, i can GET/POST/PUT to it with no problems through connector. Today I compiled a binary, fresh as an be, and it doesn't work with our webapps. On the new binary I can see it, a getEndpoints() works, getResourceValue() works, but posting to a resource seems to freeze everything. Also subscribing doesnt work, I do not get anything in my notification channel, but when I unsubscribe and then getResourceValue i get the updated value.

Are there any new requirements being enforced as far as content types, changes to the API, or other handling? I find it particularly odd that an old binary works just find and a new binary does not.

bridadan commented 8 years ago

It's worth noting that posting to a resource through cURL will also crash the device, not just by going through our libraries

BlackstoneEngineering commented 8 years ago

I deleted my API Token and replaced it with another, and now subscriptions works.... the hell?

BlackstoneEngineering commented 8 years ago

On trying to post to the device I get this response ('Error: ', 'async-responses-handler500', u'4.15 UNSUPPORTED MEDIA TYPE', '{"async-response-id":"1564631461#3109b465-fd23-4df9-8709-3c3df1900808@546a9140-9fa3-4113-b56a-883da2941d91/3201/0/5850"}')

bridadan commented 8 years ago

I deleted my API Token and replaced it with another, and now subscriptions works

I also saw this behavior

BlackstoneEngineering commented 8 years ago

I have cannot reproduce the bahavior where the device crashes, but I can confirm that POST does not seem to be working. I can also confirm that I observed radically different behavior when I generated a new API key. It seems like there was an arbitrary division and my old API key did not want to work with my new security.h

yogpan01 commented 8 years ago

I tested the same thing here yesterday and it works for us here.The POST message should use the content-type as "plain/text" otherwise the client will respond to the request with UnsupportedContentFormat and I guess that's what you are also observing. As for the API token behaviour , create issue for Device Connector.

BlackstoneEngineering commented 8 years ago

@yogpan01 Why has behavior been changed? Why is it now required to send 'plain/text' in the content field when it wasnt before? (Also, havent confirmed this to be the issue yet, still need to veryify)

yogpan01 commented 8 years ago

As per the specification, the POST on resource should have content type to be in "plain/text" format. The check was missing earlier which was found when our testers wrote test cases , this case was fixed last week.

yogpan01 commented 8 years ago

I can also do one more check on preventing this issue. We will check content type field only if there is payload included in the POST message, that way service can still execute the resource even if it doesnt have payload and we dont need to put this restriction of content type check.

BlackstoneEngineering commented 8 years ago

OK, the text type is not specified on the public API page, might want to add that there too. On Mar 10, 2016 12:33 AM, "Yogesh Pande" notifications@github.com wrote:

I can also do one more check on preventing this issue. We will check content type field only if there is payload included in the POST message, that way service can still execute the resource even if it doesnt have payload and we dont need to put this restriction of content type check.

— Reply to this email directly or view it on GitHub https://github.com/ARMmbed/mbed-client-quickstart/issues/51#issuecomment-194694634 .

BlackstoneEngineering commented 8 years ago

I have managed to duplicate this issue in 2 forms, both of these issues are seen when using the newest mbed-client-quickstart. The mbed-client-quickstart from a couple weeks ago works just fine still.

1 - POST messages are denied

Using the current master branch of https://github.com/armmbed/mbed-connector-api-python a POST message gets denied, this is the response : 

('Error: ', 'async-responses-handler500', u'4.15 UNSUPPORTED MEDIA TYPE', '{"async-response-id":"1564631461#3109b465-fd23-4df9-8709-3c3df1900808@546a9140-9fa3-4113-b56a-883da2941d91/3201/0/5850"}')

The request is being rejected, I believe because it is specifying the content type as application/json.

2 - POST messages freeze the device

using this branch of the library : https://github.com/ARMmbed/mbed-connector-api-python/tree/POST-crash-fix when sending a post I get the ('blink: ', {u'endpointName': u'3109b465-fd23-4df9-8709-3c3df1900808'}), which essentially means I sent a POST but never got anything back. The device then crashes and stops responding to commands, its registration times out after a bit.

I have confirmed the crash happening from both the node and python web apps, I have tried setting the content-type header being sent from the web app to blank, to text/plain, I have tried sending with payload and without, neither seem to work.

Steps to Replicate the issue

  1. Compile newest binary for mbed-client-examples
  2. Load / turn on board, get connected to connector
  3. verify connection by GETing the value of the button presses with API Console /5200/0/5501
  4. use web app / CURL / command line to POST to the blink resource /5200/0/5850
  5. Observe that the LED does not blink
  6. Try to use API Console to GET value of button presses again. It will fail.
  7. Try reading the console output from the board, push the button, it should print out a message like handle_button_click, new value of counter is 6, but it wont
  8. the board is frozen, the only way to get it back is to reset it.

Here is my yt ls for reference. Notice the mbed-client package is at 1.4.9, the latest as of this posting. 

mbed-client-examples 1.1.0
┗━ mbed-client 1.4.9
  ┣━ mbed-client-c 2.2.11 yotta_modules/mbed-client-c
  ┃ ┗━ nanostack-libservice 3.1.1 yotta_modules/nanostack-libservice
  ┣━ mbed-client-mbed-os 1.1.6 yotta_modules/mbed-client-mbed-os
  ┃ ┣━ mbed-drivers 1.3.0 yotta_modules/mbed-drivers
  ┃ ┃ ┣━ mbed-hal 1.2.2 yotta_modules/mbed-hal
  ┃ ┃ ┃ ┗━ mbed-hal-freescale 1.0.0 yotta_modules/mbed-hal-freescale
  ┃ ┃ ┃   ┗━ mbed-hal-ksdk-mcu 1.1.0 yotta_modules/mbed-hal-ksdk-mcu
  ┃ ┃ ┃     ┣━ uvisor-lib 2.0.0 yotta_modules/uvisor-lib
  ┃ ┃ ┃     ┗━ mbed-hal-k64f 1.2.0 yotta_modules/mbed-hal-k64f
  ┃ ┃ ┃       ┗━ mbed-hal-frdm-k64f 1.0.2 yotta_modules/mbed-hal-frdm-k64f
  ┃ ┃ ┣━ cmsis-core 1.1.2 yotta_modules/cmsis-core
  ┃ ┃ ┃ ┗━ cmsis-core-freescale 1.0.0 yotta_modules/cmsis-core-freescale
  ┃ ┃ ┃   ┗━ cmsis-core-k64f 1.0.0 yotta_modules/cmsis-core-k64f
  ┃ ┃ ┣━ ualloc 1.1.0 yotta_modules/ualloc
  ┃ ┃ ┃ ┗━ dlmalloc 1.0.0 yotta_modules/dlmalloc
  ┃ ┃ ┣━ minar 1.1.0 yotta_modules/minar
  ┃ ┃ ┃ ┗━ minar-platform 1.0.0 yotta_modules/minar-platform
  ┃ ┃ ┃   ┗━ minar-platform-mbed 1.1.3 yotta_modules/minar-platform-mbed
  ┃ ┃ ┣━ core-util 1.6.0 yotta_modules/core-util
  ┃ ┃ ┣━ compiler-polyfill 1.2.1 yotta_modules/compiler-polyfill
  ┃ ┃ ┗━ greentea-client 0.1.8 yotta_modules/greentea-client
  ┃ ┗━ sockets 1.1.3 yotta_modules/sockets
  ┃   ┗━ sal 1.1.5 yotta_modules/sal
  ┃     ┣━ sal-stack-lwip 1.3.0 yotta_modules/sal-stack-lwip
  ┃     ┃ ┣━ sal-driver-lwip-k64f-eth 1.0.6 yotta_modules/sal-driver-lwip-k64f-eth
  ┃     ┃ ┗━ sal-iface-eth 1.0.1 yotta_modules/sal-iface-eth
  ┃     ┗━ unity 2.1.0 yotta_modules/unity
  ┃       ┗━ utest 1.10.0 yotta_modules/utest
  ┗━ mbed-client-mbedtls 1.0.15 yotta_modules/mbed-client-mbedtls
    ┗━ mbedtls 2.2.1 yotta_modules/mbedtls
yogpan01 commented 8 years ago

Hi, I took the latest POST changes from mbed-connector-api repo branch and tested this again. It works fine with latest mbed-client-quickstart example

Welcome to minicom 2.7
OPTIONS: I18n 
Compiled on Jan  1 2014, 17:13:19.
Port /dev/ttyACM0, 07:39:00

Press CTRL-A Z for help on special keys

 app_start()
IP address 192.168.100.37
Device name 69802bc1-a2a7-4825-a605-61afc56c813e

SOCKET_MODE : UDP
Connecting to coap://api.connector.mbed.com:5684

Registered object successfully!
led_execute_callback pattern=500:500:500:500:500:500:500

PUT Request Received!
Name :'5853', 
Type : '1' (0 for Object, 1 for Resource), 
Type : 'Pattern'
led_execute_callback pattern="500:500:1000:500:500:500:500"
handle_button_click, new value of counter is 1
handle_button_click, new value of counter is 2
handle_button_click, new value of counter is 3
handle_button_click, new value of counter is 4
handle_button_click, new value of counter is 5
handle_button_click, new value of counter is 6
handle_button_click, new value of counter is 7

PUT Request Received!
Name :'5853', 
Type : '1' (0 for Object, 1 for Resource), 
Type : 'Pattern'
led_execute_callback pattern="500:500:1000:2000:500:2000:500"

Here is the yt ls that I have from this example

mbed-client-examples 1.1.0
┗━ mbed-client 1.4.9
  ┣━ mbed-client-c 2.2.11 yotta_modules/mbed-client-c
  ┃ ┗━ nanostack-libservice 3.1.1 yotta_modules/nanostack-libservice
  ┣━ mbed-client-mbed-os 1.1.6 yotta_modules/mbed-client-mbed-os
  ┃ ┣━ mbed-drivers 1.3.0 yotta_modules/mbed-drivers
  ┃ ┃ ┣━ mbed-hal 1.2.2 yotta_modules/mbed-hal
  ┃ ┃ ┃ ┗━ mbed-hal-freescale 1.0.0 yotta_modules/mbed-hal-freescale
  ┃ ┃ ┃   ┗━ mbed-hal-ksdk-mcu 1.1.0 yotta_modules/mbed-hal-ksdk-mcu
  ┃ ┃ ┃     ┣━ uvisor-lib 2.0.0 yotta_modules/uvisor-lib
  ┃ ┃ ┃     ┗━ mbed-hal-k64f 1.2.0 yotta_modules/mbed-hal-k64f
  ┃ ┃ ┃       ┗━ mbed-hal-frdm-k64f 1.0.2 yotta_modules/mbed-hal-frdm-k64f
  ┃ ┃ ┣━ cmsis-core 1.1.2 yotta_modules/cmsis-core
  ┃ ┃ ┃ ┗━ cmsis-core-freescale 1.0.0 yotta_modules/cmsis-core-freescale
  ┃ ┃ ┃   ┗━ cmsis-core-k64f 1.0.0 yotta_modules/cmsis-core-k64f
  ┃ ┃ ┣━ ualloc 1.1.0 yotta_modules/ualloc
  ┃ ┃ ┃ ┗━ dlmalloc 1.0.0 yotta_modules/dlmalloc
  ┃ ┃ ┣━ minar 1.1.0 yotta_modules/minar
  ┃ ┃ ┃ ┗━ minar-platform 1.0.0 yotta_modules/minar-platform
  ┃ ┃ ┃   ┗━ minar-platform-mbed 1.1.3 yotta_modules/minar-platform-mbed
  ┃ ┃ ┣━ core-util 1.6.0 yotta_modules/core-util
  ┃ ┃ ┣━ compiler-polyfill 1.2.1 yotta_modules/compiler-polyfill
  ┃ ┃ ┗━ greentea-client 0.1.8 yotta_modules/greentea-client
  ┃ ┗━ sockets 1.1.3 yotta_modules/sockets
  ┃   ┗━ sal 1.1.5 yotta_modules/sal
  ┃     ┣━ sal-stack-lwip 1.3.0 yotta_modules/sal-stack-lwip
  ┃     ┃ ┣━ sal-driver-lwip-k64f-eth 1.0.6 yotta_modules/sal-driver-lwip-k64f-eth
  ┃     ┃ ┗━ sal-iface-eth 1.0.1 yotta_modules/sal-iface-eth
  ┃     ┗━ unity 2.1.0 yotta_modules/unity
  ┃       ┗━ utest 1.10.0 yotta_modules/utest
  ┗━ mbed-client-mbedtls 1.0.15 yotta_modules/mbed-client-mbedtls
    ┗━ mbedtls 2.2.1 yotta_modules/mbedtls

I suggest we setup debug session together because after your fix branch , all GET/PUT/POST are working fine over here. But we would like to understand why is it crashing on your end.

anttiylitokola commented 8 years ago

I was able to reproduce this issue and crash was caused by uninitialized pointer. Following PR should fix the issue: https://github.com/ARMmbed/mbed-client-quickstart/pull/56

bridadan commented 8 years ago

Just tried out your PR, that fixed it! Any chance that can be merged ASAP? :D

yogpan01 commented 8 years ago

Done ! Can you close this issue now ?

bridadan commented 8 years ago

Woohoo! Closing now :)