Discussion :

[coda_blank]

Bonsoir,

je viens ici demander conseil car je suis confronté à un problème de "taille" avec libxml2 SAX en C.

J 'ai besoin de parser des fichiers xml de données 3D volumineux (>20 M) dont le contenu se trouve à 90% entre les balises (data). Je dois donc récupérer plusieurs chaines composées de dizaines voire de centaines de milliers de caractères, hors libxml limite à 4000 caractères la taille de la chaine

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

xmlChar *ch

récupérée dans la fonction de rappel. Afin éviter les attaques DOS d'après ce que j'ai compris (?!)

Faut -il procéder en plusieurs appels consécutifs pour reconstituer la totalité de chaque chaîne ?

En espérant que vous puissiez me répondre, merci d'avance .

[metagoto]

Faut -il procéder en plusieurs appels consécutifs pour reconstituer la totalité de chaque chaîne ?

Ton characters callback sera appelé plusieurs fois de suite. Tu seras donc probablement amené à maintenir un buffer le temps d'entrer dans un EndElement.

[coda_blank]

La fonction characters() "sait" que la chaine est plus grande que 4000 caractères et se lance plusieurs fois a la suite avant le traitement de endElement, c'est ca ?

Et je dois mettre a jour le buffer dans le corps de characters() ?

[metagoto]

La fonction characters() "sait" que la chaine est plus grande que 4000 caractères et se lance plusieurs fois a la suite avant le traitement de endElement, c'est ca ?

Et je dois mettre a jour le buffer dans le corps de characters() ?

Il n'y a que lors d'un changement d'état que tu peux "savoir" que le traitement précédent est terminé (pour des callbacks non atomics comme characters()) [1]. Donc si tu remplis un buffer lors des appels à characters() en ajoutant à chaque fois la chaîne qui est passée, il faudra qu'à un moment tu arrètes de remplir ce buffer. Probablement que c'est dans le endElement suivant que tu sauras au plus tôt que tout le text t'a été passé.

[1] Je n'ai jamais trop fais gaffe à cette limite de 4000 chars. Si tu es assuré que dans ta config c'est 4000 chars max qui sont passés à chaque fois (et jamais moins dans le cas où il y a plusieurs appels, sauf pour le dernier), alors un test sur le paramêtre du length pourrait t'indiquer si tu dois bufferiser ou non. Le pointer sur user_context qui t'est passé peut te servir à maintenir un état logique sur tes manips de buffering.

[sonic3516]

Bonjour,

je travaille actuellement sur un viewer de données COLLADA (exportées par XSI|Softimage) sous Ogre3D.

Pour parser le COLLADA j'utilise des fonctions basiques de ColladaDOM. Pour de petits fichiers pas de problèmes, mais dès que je teste mon code sur un fichier plus gros (toujours le même fichier de 9 Mo) le code s'avère instable : j'obtiens assez rarement l'objet dans le viewer ; la plupart du temps ça crashe avant...

J'ai alors recodé en plus bas niveau avec libxml2 le code qui me semblait pas assez robuste et pareil cela plante sur des fichiers trop gros souvent au même endroit quand je fais un énième appel de xmlNodeGetContent (tous les précédents marchent parfaitement) aux alentours du 20 ou 25 submesh du fichier...

ColladaDOM utilise libxml2 peut-être es-ce lié ?

Voilà si vous avez résolu ce genre de problème merci d'éclairer ma lanterne !

Cordialement.

[metagoto]

Lorsque les fichiers sont volumineux, il est conseillé d'utiliser l'interface xmlreader de libxml2, plutôt que DOM (tree) ou encore SAX2 (ce dernier étant considéré comme trop archaïque).

A noter que c'est la plupart du temps à l'utilisateur que revient la tache de désalouer la mémoire occupée par les xmlChar* retournés par les différentes interfaces. Se référer à la doc.

Tu as peut être un prob de mémoire non restituée...