Memory leak in FirebaseHttpClient

[gertvantslot]

I'm currently trying to use this library, but I run into some trouble (crashes).

One thing is, the SHA1 fingerprint is hardcoded into the code. The GoogleApis certificate is very volatile (one week) compared to the uptime of a sketch (I hope several months).

The other is the use of the FireBaseHttpClient. My sketch will fail during the second 2 message (FirebaseCloudMessaging) being send. Mainly because it is not freeing its memory.

I refactored some things, and now use HttpClient directly, and I supply the fingerprint via arguments. And all seems to be running fine now.

So, what am I missing, that I should use the FirebaseHttpClient?

[ed7coyne]

FirebaseHttpClient is used as a portability layer. Currently this enables unit tests to be written that will run on your workstation instead of on-device for quicker iterations using https://github.com/firebase/firebase-arduino/blob/master/contrib/test/dummies/FirebaseHttpClient_dummy.cpp .

We have experimented with porting the upper parts of the library to other architectures by implementing a FirebaseHttpClient on them, or using a portable library.

Out of curiosity what memory is not being freed?

[gertvantslot]

Thanks for the quick reply.

Now I understand. I knew I was missing something.

On every call to SendMessageToUser I could see that ESP.getFreeHeap() returned +/- 10 kB less memory. I traced this to the line in SendPayLoad where sendRequest was called.

I did not use C++ for about 20 years, that's the reason I'm not that fluent in C++ anymore. So I decided to remove everything I did not understand: FirebaseHttpClient (with the hardcoded fingerprint). And suddenly my sketch did not crash anymore.

I will undo the FirebaseHttpClient to re-test. Will keep you informed.

[gertvantslot]

It's definitely the original code that is causing the crash.

Changed the code of FirebaseCloudMessaging.cpp to the original again. And my device crashes with the second call to SendMessageToUser.

I used the following code:

const FirebaseError FirebaseCloudMessaging::SendPayload(
    const char* payload, const char* tlsFingerprint) {

  //HTTPClient client;
 
  //client.begin("https://fcm.googleapis.com/fcm/send", tlsFingerprint);
  //client.addHeader("Authorization", auth_header_.c_str());
  //client.addHeader("Content-Type", "application/json");

  //int status = client.sendRequest("POST", payload);
  //if (status != 200) {
  //  return FirebaseError(status, client.errorToString(status).c_str());
  //} else {
  //  return FirebaseError::OK();
  //}

	std::unique_ptr<FirebaseHttpClient> client(FirebaseHttpClient::create());
	client->begin("https://fcm.googleapis.com/fcm/send");
	client->addHeader("Authorization", auth_header_.c_str());
	client->addHeader("Content-Type", "application/json");

	Serial.println(ESP.getFreeHeap());
	int status = client->sendRequest("POST", payload);
	Serial.println(ESP.getFreeHeap());
	if (status != 200) {
		return FirebaseError(status, client->errorToString(status));
	}
	else {
		return FirebaseError::OK();
	}
}

The commented code is my replacement. I added the getFreeHeap() to test.

Output is:

First call:
34072
16480
Second call:
16328

The second call crashes on sendRequest, so only one getFreeHeap is printed.

[ed7coyne]

Hmm... that is good to know. Let's look into that. Thanks for reporting it!

[gertvantslot]

I mixed in the standard Firebase methods (set, push) in my test.

Note: Using the current code it is not possible to mix the Cloud messaging and Firebase, because the Cloud messaging uses a certificate from *.googleapi.com, and firebase uses *.firebaseio.com. They have a different fingerprint, and you can set only one in FirebaseHttpClient.h.

Free memory at the start of my sketch is 35,000 bytes.

When using the Cloud Messaging and HttpClient, free memory (in my test) seems to stabilize at 34,000, and there is a dip to 15,000 during sending of the message. But within one second, free memory is back to 34,000.

When using Firebase methods, free memory stabilizes at 16,000.

Mixing Firebase database and cloud messaging crashes the sketch. Because memory consumption is too much.

My findings:

• A call to Firebase (Cloud Messaging or database) uses +/- 16,000 bytes.
• FirebaseHttpClient does not release it's memory when being used.
• Normal HttpClient usage does not consume that amounts of memory

[proppy]

Seems similar to #251

[proppy]

@gertvantslot thanks again for the detailed report, and sorry for the late follow-up.

I wonder if this was fixed with esp8266/Arduino@bf5a0f2 ?

Filed #347 to track the fingering issue with FCM.