Julian Büchel

I updated to the newest version and the leak is still there. I also suspect that it is this file. @MathiasCraeghs can you reopen the issue? Or did you find...

As I posted in [this](https://github.com/espressif/esp-azure/issues/76) issue, the number of leaked bytes is quite low for me as well (~100 bytes per callback call). Can you explain a little bit more...

I am using the repo with the last commit 5f421bbd7ef8e6f5502204e9cd7a5f494070b39a with the commit message : Merge branch 'bugfix/big_chunk_read_fix' into 'master'

Are there any news regarding this?

Exactly. I am using https://github.com/Azure/azure-iot-sdk-c/blob/master/iothub_client/samples/iothub_client_sample_upload_to_blob_mb/iothub_client_sample_upload_to_blob_mb.c as a template. Thanks for your help!

Are you able to reproduce this issue? At this commit, the esp-azure repo is using azure-iot-sdk-c @ a0188ac . This is critical for us since our application is already running...

Everything seems to compile fine, but then this occurs: ``` Generating libwifi_synch.a.sections_info Generating esp32.project.ld LD build/app-template.elf /home/julian/Documents/chaze-esp32/build/wifi_synch/libwifi_synch.a(wifi_synch.o):(.literal._Z16synch_with_azurev+0x4): undefined reference to `HTTP_Protocol' /home/julian/Documents/chaze-esp32/build/esp-azure/libesp-azure.a(httpapiex.o):(.literal.HTTPAPIEX_ExecuteRequest+0x14): undefined reference to `HTTPAPI_Init' /home/julian/Documents/chaze-esp32/build/esp-azure/libesp-azure.a(httpapiex.o):(.literal.HTTPAPIEX_ExecuteRequest+0x18): undefined reference to...

It is compiling now. I had to add ``` azure-iot-sdk-c/iothub_client/src/blob.o \ azure-iot-sdk-c/iothub_client/src/iothubtransporthttp.o \ azure-iot-sdk-c/c-utility/adapters/httpapi_compact.o \ ``` to ```component.mk```. But now I get the following error message: ``` Info: Waiting for...

Everything is working now, but the memory leak is still not gone. I suspect that the reason is not from Msft, but from ESP.

Hi, what is the status on that? I am trying to use greyscale images with FFCV. I'd prefer to avoid a workaround. This flag seems nice.