[Delphi] Indy TCP server functioneert niet

Pagina: 1
Acties:
  • 113 views sinds 30-01-2008
  • Reageer

  • ikke007
  • Registratie: Juni 2001
  • Laatst online: 22-10-2025
Ik ben aan een client - server applicatie bezig in Delphi 2005 met behulp van Indy 9 (gezien deze applicatie is gestart in Delphi 7). Echter sinds gisteren krijg ik het niet meer 'functionerend' gecompileerd. Ik zal het proberen kort te omschrijven, maar ik heb al zoveel dingen geprobeerd....

Gedurende het ontwikkelen ging het steeds meer de goede kant op. Echter ben ik gisteren tegen een zeer aparte *bug/feature* aangelopen. Spontaan wilde mijn werk wat ik had gecompiled niet meer functioneren. Ik zeg hier functioneren omdat de compile geen fouten,hints of warnings opleverde maar dus niet correct functioneerd.

Als ik mijn server start en hier naartoe telnet krijg ik de standaard greeting. Ik kan nu gewoon commando's op mijn server afvuren welke hij netjes behandelt of denyd (Unknown command).

Nu logt een tweede telnet sessie in, deze krijgt ook de standaard greeting. Echter wat ik hier ook in tiep aan commando's, de server reageert er niet op.

Builden,compilen, het maakt niet uit, de bug remains. Ik krijg vreemd genoeg geen exceptions of iets dergelijks. Wat ik wel heel erg 'raar' vind is dat als ik de codeflow volg dmv een breakpoint ik op een gegeven moment in de Indy 9 code terrecht kom en dat hier de breakpoint balletjes niet correct op alle coderegels staan. - Het staat soms op witregels, op commentaar en bij veel statements staat er geen balletje alsof de optimizer vind dat die regels at random niet hoeven te worden gedaan.

He is ook niet zo alsof het altijd de eerste client is die wel alles mag doen en de tweede niet, want als ik als eerste in de telnet sessie welke als tweede inlogt wat tiep krijgt deze de 'focus' en kan de eerste telnetsessie geen werking meer krijgen. Bij drie telnetsessies geen verschil, ook degene die ik als eerste wat laat doen krijgt de focus en de andere twee sessies doen niets meer.

Bij het sluiten van mijn server worden alle threads opgeruimd in de code. nu krijg ik spontaan en acces violation van EOSError wat een eoserror is. Hierop heb ik gegoogled maar dit levert enkel dingen op dat je thread iets visueels in je server doet, wat bij mij niet het geval is.

Mijn code nagelopen, alle keren dat ik threads lock omdat ik er iets mee doe worden deze ook unlocked.

Omdat ik het zo'n rare melding vind heb ik mijn code van 3 dagen geleden uit SVN gehaald wanneer ik zeker wist dat deze werkte, en ook deze kan ik niet meer functionerend compileren.

Wie o wie heeft ooit dit vage verhaal meegemaakt/herkend hier flarden in!??

nb: foutmelding =
Exception EOSError in module bePatientServer.exe at 0000F940.
System Error. Code: 1400.
Ongeldige vensteringang.

Lets remove all security labels and let the problem of stupidity solve itself


  • LordLarry
  • Registratie: Juli 2001
  • Niet online

LordLarry

Aut disce aut discede

Dat je ballatjes in de IDE niet meer lijken te kloppen komt omdat je code gecompiled is met een andere source dan dat je bij het debuggen zit te kijken.

We adore chaos because we like to restore order - M.C. Escher


  • ikke007
  • Registratie: Juni 2001
  • Laatst online: 22-10-2025
Hmm, weet je ook een manier om dat probleem te verhelpen? Want ik heb niet zitten rotzooien in mijn Indy Componenten map waar dit dus in voorkomt...

Lets remove all security labels and let the problem of stupidity solve itself


  • martijn_brinkers
  • Registratie: November 2001
  • Laatst online: 31-10-2025
Je kan ook een mismatch krijgen met de debugger en source als je CR+LF en CR (of alleen LF) door elkaar gebruikt. Het is mij wel eens overkomen dat winCVS mijn code 'patchte' met CR ipv CR+LF. Delphi raakte daar flink van in de war (dwz source en debug komt niet overeen zoals jij beschrjft). Koste we wat tijd voor ik doorhad wat er mis was. Het zou kunnen zijn dat dat bij jouw ook het geval is. Ik dacht dat de oplossing in mijn geval was de .pas file inlezen in Notepad en die dan weer wegschrijven.

zie oa:

http://groups.google.com/...3%26#doc_ec336773dcf8fd9d

[ Voor 28% gewijzigd door martijn_brinkers op 20-02-2006 16:00 ]


  • ikke007
  • Registratie: Juni 2001
  • Laatst online: 22-10-2025
Toch is dat wel erg apart omdat die mismatch optreed in de IdTCPServer en IdThread van Indy, welke niet worden meegenomen in mijn SVN.

Daarnaast; is dit enkel een visuele mismatch of doet de compiler daardoor dus ook rare dingen?

Nb: ik heb al mijn bestanden van mijn project handmatig door kladblok gehaald en opnieuw opgeslagen; maar dat gaf niet het gewenste resultaat...

Lets remove all security labels and let the problem of stupidity solve itself


  • LordLarry
  • Registratie: Juli 2001
  • Niet online

LordLarry

Aut disce aut discede

Nee, het is alleen een visuele mismatch, maar kan wel betekenen dat er andere source gebruikt is om te compilen dan jij denkt. De oplossing is eerst alles wat met Indy te maken heeft handmatig van je computer halen en daarna de gewenste versie installeren. Bij dat handmatig verwijderen moet je alle .pas, .dcu, .dpk, .bpl en .dcp bestanden die met Indy te maken hebben van je schijf verwijderen.

We adore chaos because we like to restore order - M.C. Escher


  • ikke007
  • Registratie: Juni 2001
  • Laatst online: 22-10-2025
Het probleem is opgelost

De oplossing kwam doordat een van mijn mededevelopers een visuele procedure had geplakt aan de DoBeforeCommandhandler. Dit op zich is niet zo erg maar deze procedure moest wat toevoegen aan een list op het scherm. Echter was door een compiler directive deze niet zichtbaar wat op de een of andere manier tot een onzichtbare exception resulteerde....

Lets remove all security labels and let the problem of stupidity solve itself

Pagina: 1