problem avec les buffer: taille max

Ce si est un bou de code de mon programme "lss":

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

long pduLen; int maxPduLength //maxPduLength_ if it is set to 0 this mean thatno control is done in the PDU size //if the value is 0 , the maxPduLength will not be taken into account //pduLen is the real PDU length   SSC_DebugTrace <<"maxPduLength_ is set to "<< maxPduLength_ << endl; if(maxPduLength_ != 0) { if (pduLen > maxPduLength_) pduLen = maxPduLength_; } SSC_DebugTrace <<"PduLen is set to "<< pduLen << endl;   char* buf = new char[pduLen + 1l]; result = receiveSocketData(buf, (int) pduLen);

---

Ce programme Marche a merveille ( sur plusieurs machine LINUX, SUN, HP).
a l'exception d'une machine "HP-UX ipb228 B.11.23 U ia64 1545032245" c'est une HP Itamium.
dans ma console j'ai le message suivant:

End of LSS initialisation.

Citation:

---

aCC runtime: Uncaught exception of type "bad_alloc".
[HP ARIES32]: Error occured while writing core file for 32 bit
[HP ARIES32]: PA-RISC application /alu/1350OMS9.1/NMC/SEC/7.2.1/lss/bin/lss (got signal 6).
[HP ARIES32]: Core file may not be correct.

---

dans les fichiers de traces j'ai le message suivant:

Citation:

---

-->SLAC_Sock::fdOk
<--SLAC_Sock::fdOk
maxPduLength_ is set to 0
PduLen is set to 1195986768
EndLSS by signal 6.

---

je ne sais pas exactement la cause du crach du programme (lss).
Mais je pense que ce probl�me est due au d�passement de la taille max que je peu alloue a un buffer dans cette machine.
c'est possible aussi que la PDU soit corrompu ou bien sans le caract�re NULL (\0) en fin de PDU.

Est ce qu'il a quelqu'un qui peut me dire si le probl�me provient de l'un des causes que j'ai �voque.
Est ce qu'il a quelqu'un qui peu me donne une fa�on en c++ comment je peu pr�venir c'est deux probl�me (taille max du buffer sur une machine, PDU corrompu).

Merci

Bonjour et bienvenu,
J'imagine que le bout de code est partiel et que pduLen est bien initialis� avant d'�tre utilis�!
Revenons sur ton probl�me:
1/Echec de l'allocation car taille trop importante: c'est possible. Pour g�rer les �chec d'allocations, le mieux est que tu traites les exceptions lev�es dans le bout de code o� tu fais cette allocation.
2/M�moire corrompue: si tu sous entend que ton programme a d�bord� sur un buffer quelque part, je ne suis pas s�r que cela puisse �tre d�tect� automatiquement. Il faudrait encapsuler tes buffers dans une classe qui pourrait v�rifier si le buffer a �t� alt�r� ou si l'�criture a d�bord� (en encadrant le buffer de marqueur, en adjoignant un checksum sur le buffer et avec des interfaces type Lock/Release pour obtenir l'@ et la rel�cher).
3/ Allouer un buffer de plus de 1 Go pour une r�ception sur une socket: voil� quelque chose d'assez ambitieux. As-tu d�j� r�ussi � transf�rer une telle quantit� de donn�e sur un seul packet UDP? Je pense que tu as une incoh�rence sur cette donn�e. Sinon, � mon avis, il faut revoir ton protocole d'�change.
Voil�.
Bon courage.

Citation:

---

Envoy� par 3DArchi

3/ Allouer un buffer de plus de 1 Go pour une r�ception sur une socket: voil� quelque chose d'assez ambitieux. As-tu d�j� r�ussi � transf�rer une telle quantit� de donn�e sur un seul packet UDP? Je pense que tu as une incoh�rence sur cette donn�e. Sinon, � mon avis, il faut revoir ton protocole d'�change.

---

Pour compl�ter la r�ponse de 3DArchi, trouv� dans le RFC 768
La longueur d'un datagramme UDP est cod�e sur 2 octets. Cette longueur comprend aussi la taille du header UDP (4 octets). La longueur des donn�es d'un paquet UDP ne peut donc d�passer 65535 - 4 = 65531 octets.