Discussion :

[darckangel7]

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

Code :

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

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.

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:

-->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

[3DArchi]

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.

[ram-0000]

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.