![]() |
Hej och välkommen från USA till UNIX och Linux Forum! Tack för ditt besök och gå med i vår globala gemenskapen.
|
|
google unix.com
|
|||||||
| Forum | Registrera | Forum Regler | Länkar | Album | FAQ | Medlemslista | Kalender | Söka | Dagens inlägg | Markera forum som lästa |
| IP Nätverk Läs TCP / IP, Internet Protocol, Routing, Routrar, Nätverksprotokoll i UNIX och Linux forum. |
Mer UNIX och Linux Forum Ämnen Du kan hitta Helpful
|
||||
| Tråd | Thread Starter | Forum | Svar | Senaste Inlägg |
| Problem med minnesläcka | kshk123 | HP-UX | 2 | 05-25-2009 07:01 |
| minnesläcka problem | Sonali | High Level Programming | 5 | 05-25-2009 06:55 |
| Minnesläcka i pthread | mindTeaser | UNIX för avancerade & Expertanvändare | 4 | 05-18-2009 01:30 |
| Minnesläcka i gaffel () | whererush | High Level Programming | 7 | 05-11-2006 11:51 |
| om virtuellt minne och minnesläcka | shriashishpatil | High Level Programming | 4 | 02-20-2006 11:31 |
![]() |
|
|
LinkBack | Thread Tools | Sök i denna tråd | Rate Thread | Visningslägen |
|
|
|
||||
|
minnesläcka?
Hej Alla,
Min klient-server applikation kan arbeta i två lägen: 1) en riktning - bara klienten skickar msgs till server 2) två riktningar - servern ger "svar" till kund. När programmet körs i första läget ser det ut OK, men när servern svar till klienten än kundens begäran lämna verksamheten efter en kort stund. Jag försöker hitta problemet men har några taugh tid. Detta är den funktion som läser data på klientsidan (som jag har problem): Kod:
int TCPClient::readSocketData(int s,
char *decodeUnifiedMsgForServer,
int n,
bool& isMsg
)
{
int bcount; int br;
bcount = 0;
br = 0;
while (bcount < n)
{
if ((br = recv(s,decodeUnifiedMsgForServer,n-bcount,0)) > 0)
{
isMsg = true;
bcount += br; decodeUnifiedMsgForServer+= br;
}
else if (br < 0) /* signal an error to the caller */
{
return(-1);
}
else {
return bcount;
}
//Y 17_04_05 -
Sleep(0);
//Y.
}
return(bcount);
}
Kod:
void BrainControlComData::decodeMsg(char* decodeUnifiedMsgForServer)
{
if(strlen(decodeUnifiedMsgForServer) == 0)
{
char* error = "probably an error (see Q1 below)";
}
char* msg = decodeUnifiedMsgForServer;
int size = 4;
int lenCursorData;
int lenManipData;
int lenVzData;
//places 1 - 12 in msg are reserved for total size/ isEventMsg/ MsgID
int Web_lenOfClass;
// decode len of msg
memcpy(&Web_lenOfClass, msg, size);
int lenOfClass = ntohl(Web_lenOfClass);
int Web_MsgID;
// decode msg ID
memcpy(&Web_MsgID, msg + MSG_ID_LOCATION, size);
int msgID = ntohl(Web_MsgID);
//Y 6_07_05 -
int counter = 12;
int len = 0;
len = comData[CURSOR_DATA]->decodeMsg(msg + counter);
counter += len;
len = comData[STATE_DATA]->decodeMsg(msg);
}
Mina frågor är följande: 1) Varför är längden på den buffert (decodeUnifiedMsgForServer) är alltid 0 och inte lika med längden på msg från servern? Jag vet att de uppgifter som tas emot från servern eftersom det är inloggad korrekt, men när jag kolla längd msg det equas 0 (först "om" i andra funktion) - några idéer? 2) när jag anmärkte linje som kallar decodeMsg ansökan "uppträdde" OK och klient inte avsluta sin verksamhet. Jag tror att detta fel har något att göra med minnesläcka. Kanske om jag förstod den första frågan jag kunde förstå den här också. Tack så mycket för hjälpen, Lenna |
|
||||
|
Tja, jag vet inte svaret på den första frågan, men jag nog reda på svaret för seconf en. anledningen till att programmet blev galen är att eftersom det är flera threading finns en situation där en händelse har uppstått, vilket leda till att systemet galen. Jag fortfarande inte har hittat varför det freaks ut men om jag förhindra att händelsen höjas än avverkningen är OK och klientprogram är inte avsluta sin verksamhet.
Jag blir glad även om någon kunde svara på min första fråga ovan - varför är längden av buffert \u003d 0? kan det bero på att jag använder memcpy i min koda / avkoda buffert funktioner? tack igen Lenna |
|
||||
|
Använd Debugger ...
Hello Lenna,
Det är ett komplext program, och de problem som kan stå på olika ställen så använd debugger för att utreda den exakta orsaken. Men jag har gjort några observationer kod: 1. Om "TcpClient:: readSocketData" Om fjärrkontrollen sidan stänger uttaget för skrivning (avstängning uttaget) eller stängs. då funktionen "recv" returnerar 0 Se man Recv "Avkastningen värdet vara 0 när de inbördes har utfört en ordnad avstängning." Denna metod kommer exit vid andra retur eftersom "br" kommer att vara 0 och avkastningen värdet vara 0. Så alla data i bufferten kommer inte berörs alls. Jag rekommenderar också att du använder errno och # include <errno. h> för att kontrollera felet efter varje misslyckat samtal. Jag recomment dig kontrollera fel. 2. Ha i åtanke att om du testar både klient och server på samma dator (localhost) som lämnar klienten med oavslutade uttag gör att servern för att få SIG_PIPE signal. Så jag rekommenderar er att blockera den signal på servern. 3. Metoden "BrainControlComData: decodeMsg (char * decodeUnifiedMsgForServer)" har ingen aning om bufferten längd. char * är en pekare till en byte eller byte sekvens Jag recomment dig att ändra deklarationen till BrainControlComData:: decodeMsg (const char * decodeUnifiedMsgForServer, size_t storlek) Det är därför dessa rader ser konstigt ut: if (strlen (decodeUnifiedMsgForServer) \u003d\u003d 0) ( char * error \u003d "förmodligen ett fel (se Q1 nedan)"; ) Jag antar att decodeMsg helt enkelt inte får bufferten med rätt längd, och det inte gör några kontroller om rätt längd. Det förutsätter att allt är OK, och när det är inte sant att du får konstiga resultat. Den memcpy är inte nödvändig int Web_lenOfClass; / / Avkoda len av msg memcpy (& Web_lenOfClass, msg, storlek); int lenOfClass \u003d ntohl (Web_lenOfClass); Du kan ersätta det med: int lenOfClass \u003d ntohl (* (uint32_t *) msg); och även int msgId \u003d ntohl (* (uint32_t *) (msg + MSG_ID_LOCATION)); 4. Om du har tid skulle jag rekommendera dig att skapa enhet (provningar isolerat) om varje viktig klass / metoder. Och att kontrollera dem mer noggrant. Fler tester med mer detaljerade tester. Vänliga hälsningar O. Senast redigerad av ogerassimov; 05-25-2009 at 01:03.. |