gsoap fuite de mémoire C applications

Question

Nous utilisons gsoap pour les services web client et serveur C mis en œuvre pour blackfin sous Linux.

Nous n'utilisons aucun malloc dans l'application. Mais nous constatons que l'utilisation de la mémoire grimpe avec le temps. Nous utilisons soap_end pour faire un nettoyage à la fin de l'appel. Mais lorsque les appels sont invoqués à plusieurs reprises, l'utilisation de la mémoire augmente lentement, peut-être à cause de la fragmentation de la mémoire. Cela a également un impact sur les performances du système

Quelle est l'utilisation préférée de gsoap où soap_malloc n'est pas beaucoup utilisé. Par exemple: Si nous utilisons des tableaux statiques, cela aidera-t-il?

Merci,

NKR

Answer 1

Je recommande de ne pas utiliser des données statiques, il n'y a pas besoin de cela.

Pour déboguer l'utilisation de la mémoire, compilez tous vos fichiers sources avec -DDEBUG. Lorsque vous exécutez votre application, vous verrez trois fichiers:

• SENT.log les messages envoyés
• RECV.log les messages reçus
• TEST.log le journal de débogage

Le TEST.log est utile de vérifier sur les questions de messagerie .

Les autres informations importantes générées lors de l'exécution sont des messages d'erreur liés aux fuites de mémoire ou à la mémoire de segment endommagée (par exemple, dépassements) dans votre code. Il est peu probable que cela se produise dans le moteur gSOAP, mais mieux vérifier.

Pour assurer une bonne répartition et désaffectation des données gérées:

soap_destroy(soap); 
soap_end(soap); 

J'utilise les fonctions générées automatiquement à affecter les données gérées par:

SomeClass *obj = soap_new_SomeClass(soap); 

et utiliser de façon sporadique soap_malloc pour l'allocation gérée brute, ou pour allouer un tableau de pointeurs, ou une chaîne C:

const char *s = soap_malloc(soap, 100); 

mais mieux est d'allouer des chaînes avec:

std::string *s = soap_new_std__string(soap); 

et réseaux peuvent être attribués au second paramètre, par exemple, un tableau de 10 chaînes:

std::string *s = soap_new_std__string(soap, 10); 

Toutes les allocations gérées sont supprimés avec soap_destroy() suivi par soap_end(). Après cela, vous pouvez commencer à allouer à nouveau et supprimer à nouveau, etc.

Si vous souhaitez conserver des données qui obtient autrement avec ces appels supprimés, utilisez:

soap_unlink(soap, obj); 

Maintenant obj peut être retiré plus tard avec delete obj.Mais sachez que tous les membres de pointeur dans obj pointant vers des données gérées sont devenus invalides après soap_destroy() et soap_end(). Il se peut donc que vous deviez appeler soap_unlink() sur ces membres ou risquer des pointeurs qui pendent.

Une nouvelle fonctionnalité intéressante de gSOAP est de générer une copie en profondeur et supprimer la fonction pour toutes les structures de données automatiquement, ce qui permet d'économiser une énorme quantité de temps de codage:

SomeClass *otherobj = soap_dup_SomeClass(NULL, obj); 

Duplicata obj à l'espace de tas non géré. Ceci est une copie profonde qui vérifie les cycles dans le graphe d'objets et supprime ces cycles pour éviter les problèmes de suppression. Vous pouvez également dupliquer l'objet géré (cyclique) entier vers un autre contexte en utilisant soap au lieu de NULL pour le premier argument de soap_dup_SomeClass.

DEEP Supprimer:

soap_del_SomeClass(obj); 

Cela supprime obj mais aussi les données pointée par ses membres, et ainsi de suite.

Pour utiliser les soap_dup_X et soap_del_X fonctions utilisent soapcpp2 avec des options -Ec et -Ed, respectivement.

En principe, les données statiques et allouées par pile peuvent également être sérialisées. Mais pensez à utiliser le tas géré à la place.

Espérons que cela aide.