[VB6 sp5]Reden voor hangen applicatie

Pagina: 1
Acties:

  • Tukk
  • Registratie: Januari 2002
  • Laatst online: 12:38

Tukk

De α-man met het ẞ-brein

Topicstarter
Ik heb een applicatie gemaakt in VB6 die periodiek een call uitvoert naar een UNIX server en de reply van de server verwerkt.

De periodieke call wordt uitgevoerd met behulp van het timer event, de reply is een antwoord dat wordt ontvangen op een socket. Dit antwoord wordt verwerkt tot een event door een third-party OCX en ik ontvang in mijn applicaitie een event op deze OCX met al parameter de de ontvangen string.

Het probleem is het feit dat het proces soms blijft hangen. Het doet niets meer en geen enkel event wordt meer uitgevoerd. Dit hangen is niet tijdens het uitvoeren van code, maar in de tijd dat het proces niets hoeft uit te voeren.

Timer:
code:
1
2
3
4
5
tmrPeriodiek_Timer()
  log 1
  ThirdpartyOcx.call("Vraag om data")
  log 2
end sub


Ontvangen data:
code:
1
2
3
4
5
6
7
8
OCXSock_OnSocketReceive(host as string, data as string)
   log 3
   zet timer uit
   Knip de string uit elkaar, verwerk de string
   Plaats de verwerkte data op een DCOM Server
   zet timer aan
  log 4
end sub


Als ik in de logging nu als laatste een 1 of een 3 zou zien staan, dan is het debuggen geen probleem, maar als laatste zie ik een 4.

De handles, het geheugen en de processorkracht van het proces lijken normaal.

Mijn vragen:

• Heeft iemand ooit gehoord van de Timer-OCX van VB6 die zijn event niet meer af laat gaan? Ik heb niet kunnen vinden daarover op www.microsoft.com of google.

• Wat zou een reden kunnen zijn voor een applicatie om niet meer te reageren op elke prikkel die het krijgt. Ook 'End process' vanuit taskmanager komt met een time-out indien deze netjes vraagt of het proces wil afsluiten. Hierdoor denk ik persoonlijk dat het probleem niet bij het timer event ligt.

Q: How many geeks does it take to ruin a joke? A: You mean nerd, not geek. And not joke, but riddle. Proceed.


  • Markieman
  • Registratie: December 2001
  • Laatst online: 15-05 12:16
foutje

[ Voor 93% gewijzigd door Markieman op 04-05-2004 14:47 ]

You do not fear them? - The Wraith? Naah. Now *clowns*, that's another story.


  • Markieman
  • Registratie: December 2001
  • Laatst online: 15-05 12:16
Die timer heeft bij mij altijd perfect gewerkt.

Is die third-party OCX wel betrouwbaar? Misschien zit daar gewoon een fout in...

You do not fear them? - The Wraith? Naah. Now *clowns*, that's another story.


  • Tukk
  • Registratie: Januari 2002
  • Laatst online: 12:38

Tukk

De α-man met het ẞ-brein

Topicstarter
Markieman schreef op 04 mei 2004 @ 14:46:
Die timer heeft bij mij altijd perfect gewerkt.

Is die third-party OCX wel betrouwbaar? Misschien zit daar gewoon een fout in...
Dat is ook de reden waarom ik deze vermeld, ik wil de rest kunnen uitlsuiten eer ik me in het moeilijke pad van deze oplossing stort. Ik kan nu namelijk niets bewijzen.

Een reden waarom ik twijfel om de third-party niet als de schuldige aan te wijzen is het feit dat de functie waarin deze gebruikt wordt netjes afloopt. De ocx wordt dan toch niet meer gebruikt. :?

Q: How many geeks does it take to ruin a joke? A: You mean nerd, not geek. And not joke, but riddle. Proceed.


  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

sluit je de OCX die je aanroept wel op de juiste manier af? Misschien dat het ding nog op een instructie staat te wachten en daarom de wachtrij volhoudt?

Als de app echt zou vastlopen in de wachtperiode tussen de aanroepen in lijkt me dat erg sterk. Misschien is je app zo druk bezig dat het loggen nog niet verwerkt is als je gaat checken? Wellicht dus even (ter test) een DoEvents achter elke log-actie hangen (of in de log-procedure) om te kijken waar hij zich nou werkelijk ophangt?

[ Voor 5% gewijzigd door OZ-Gump op 05-05-2004 00:00 ]

My personal website


  • Tukk
  • Registratie: Januari 2002
  • Laatst online: 12:38

Tukk

De α-man met het ẞ-brein

Topicstarter
OZ-Gump schreef op 04 mei 2004 @ 23:59:
sluit je de OCX die je aanroept wel op de juiste manier af? Misschien dat het ding nog op een instructie staat te wachten en daarom de wachtrij volhoudt?

Als de app echt zou vastlopen in de wachtperiode tussen de aanroepen in lijkt me dat erg sterk. Misschien is je app zo druk bezig dat het loggen nog niet verwerkt is als je gaat checken? Wellicht dus even (ter test) een DoEvents achter elke log-actie hangen (of in de log-procedure) om te kijken waar hij zich nou werkelijk ophangt?
Ik denk zelf niet dat het in het loggen licht. De code die daarbij gebruikt wordt
is vaak gebruikte code die mij/ons nog nooit in de steek heeft gelaten.
Daarbij is het steeds de 4 die ik als laatste zie, dit zou niet zo zijn als de fout in de logging zou zitten, dan zou ik minimaal zo nu en dan de 2 als laatste moeten zien.

De OCX moet blijven leven. Ik zou ook nog andere info kunnen ontvangen.

Q: How many geeks does it take to ruin a joke? A: You mean nerd, not geek. And not joke, but riddle. Proceed.


  • farlane
  • Registratie: Maart 2000
  • Laatst online: 22-05 16:53
Haal die ocx er eens uit en simuleer het gedrag van dat ding. Blijft ie leven, dan is de kans al weer wat groter dat het aan die ocx ligt.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • Tukk
  • Registratie: Januari 2002
  • Laatst online: 12:38

Tukk

De α-man met het ẞ-brein

Topicstarter
farlane schreef op 05 mei 2004 @ 12:01:
Haal die ocx er eens uit en simuleer het gedrag van dat ding. Blijft ie leven, dan is de kans al weer wat groter dat het aan die ocx ligt.
Tja, als die OCX er niet is zal de app niets doen dan een timer om de 3 seconden laten afgaan, dat zal wel blijven leven. Of het dan echt de OCX, de hoeveelheid acties de de app moet doen(lees: windows probleem) of de code van mijzelf is weet ik dan nog niet, toch?

Ik zal de vraag simpeler stellen, wat kan de oorzaak zijn dat een proces, dat geen code uit te voeren heeft laten hangen.

Ik bedenk me dat ik 1 mogelijk belangrijk feit ben vergeten te melden, het OS is winnt 4.0 Sp6a.

Q: How many geeks does it take to ruin a joke? A: You mean nerd, not geek. And not joke, but riddle. Proceed.


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 00:01

Janoz

Moderator Devschuur®

!litemod

Flush je je log wel? Ik weet niet hoe je precies aan het loggen bent, maar het kan best zijn dat de printbuffer van de log messages pas wordt geflushed waneer je programma 'in de wacht gaat'. Dit zou verklaren waarom je log altijd met een 4 eindigd. Dit probleem heb ik zelf meerdere malen gehad bij een c++ programma dat ik probeerde te debuggen :). Misschien moet je het programma anders gewoon even in een debugger draaien. Of loopt het maar sporadisch vast?

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Tukk
  • Registratie: Januari 2002
  • Laatst online: 12:38

Tukk

De α-man met het ẞ-brein

Topicstarter
Janoz schreef op 05 mei 2004 @ 22:26:
Flush je je log wel? Ik weet niet hoe je precies aan het loggen bent, maar het kan best zijn dat de printbuffer van de log messages pas wordt geflushed waneer je programma 'in de wacht gaat'. Dit zou verklaren waarom je log altijd met een 4 eindigd. Dit probleem heb ik zelf meerdere malen gehad bij een c++ programma dat ik probeerde te debuggen :). Misschien moet je het programma anders gewoon even in een debugger draaien. Of loopt het maar sporadisch vast?
Ik log in een logfile.
Het loopt om de 2 tot 24 uur vast.

De debugger optie is een probleem, maar wel iets wat nog op het lijstje staat wat er te proberen valt.

Q: How many geeks does it take to ruin a joke? A: You mean nerd, not geek. And not joke, but riddle. Proceed.


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
• Log is een gereserveerd woord... Gebruik liever iets anders als LogString of whatever...
• Je moet je file, zoals Janoz al aangeeft, effe voor de zekerheid flushen. Dat doe je dus door je Log routine als volgt te maken:

Visual Basic:
1
2
3
4
5
6
7
8
Public Sub LogString(strMessage as string)
    Dim ff As Integer
    
    ff = FreeFile
    Open "C:\mylog.txt" For Append As #ff
    Print #ff, Now & ": " & vbTab & strMessage
    Close #ff
End Sub


Het steeds openen en sluiten is (zeker als er veel gelogd wordt) niet erg efficiënt, maar zo weet je zeker dat je file geflushed wordt.

• Log voor de gein eens Err.Number en Err.Description mee (dus LogString "Event 1 " & err.number & " - " & err.description ofzo)
• Controleer je code eens op "On error resume next" en andere enge dingen (die zorgen bij een beginnende collega van mij nogal eens voor vage problemen doordat er met objecten wordt gewerkt die niet ge-set zijn e.d. en 't spul huppelt dan vrolijk verder... :X )
• Zorg voor een goede error-handling en gooi daar ook een LogString in ofzo.
• Log eventueel ook alle ontvangen en verstuurde data, misschien kun je hieruit iets opmaken? (De laatst ontvangen data zorgt misschien voor een probleem?)
• Controleer of je alle objecten ook weer netjes vrijgeeft/closed e.d. als je ze niet meer nodig hebt (kijk ook eens naar het geheugengebruik van je app e.d.)

...just my €0.02 (of €0.0238 inc. BTW :) )

[ Voor 54% gewijzigd door RobIII op 05-05-2004 23:01 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Verwijderd

RobIII schreef op 05 mei 2004 @ 22:56:
• Log voor de gein eens Err.Number en Err.Description mee (dus LogString "Event 1 " & err.number & " - " & err.description ofzo)
Ook een leuk truukje is om weer ouderwets regelnummers in je code op te nemen en dan naar err.number en err.description ook de (undocumented) Erl() functie op te nemen, dan zie je ook in welke regel het fout is gegaan ! Gebruik voor het toevoegen van de regelnummers trouwens de Freeware MZ-tools addin voor vb (http://www.mztools.com, een aanrader voor iedere VB-programmeur), die heeft daar een optie voor.

  • farlane
  • Registratie: Maart 2000
  • Laatst online: 22-05 16:53
Tukk schreef op 05 mei 2004 @ 21:55:
Tja, als die OCX er niet is zal de app niets doen dan een timer om de 3 seconden laten afgaan, dat zal wel blijven leven.
Volgens mij gebeurt er nog meer in die onreceive van dat component.
Ik zal de vraag simpeler stellen, wat kan de oorzaak zijn dat een proces, dat geen code uit te voeren heeft laten hangen.
Ik zal hem simpel beantwoorden :
- locking probleem ( deadlock )
- timing pobleem
- bug
- all of the above
- none of the above

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • Tukk
  • Registratie: Januari 2002
  • Laatst online: 12:38

Tukk

De α-man met het ẞ-brein

Topicstarter
RobIII schreef op 05 mei 2004 @ 22:56:
• Log is een gereserveerd woord... Gebruik liever iets anders als LogString of whatever...
• Log voor de gein eens Err.Number en Err.Description mee (dus LogString "Event 1 " & err.number & " - " & err.description ofzo)
• Controleer je code eens op "On error resume next" en andere enge dingen (die zorgen bij een beginnende collega van mij nogal eens voor vage problemen doordat er met objecten wordt gewerkt die niet ge-set zijn e.d. en 't spul huppelt dan vrolijk verder... :X )
• De code die je ziet grotendeels pseudo code, zoals ik eerder melde roep ik een functie aan die de logging in en file zet
• Ik log de foutmelding zoals jij hier boven aangeeft, ik krijg alleen geen foutmelding. Het proces reageert vanaf een bepaald moment gewoon nergens meer op.
• ik gebruik *nooit* On error resume next. :/
Verwijderd schreef op 06 mei 2004 @ 01:19:
[...]

Ook een leuk truukje is om weer ouderwets regelnummers in je code op te nemen en dan naar err.number en err.description ook de (undocumented) Erl() functie op te nemen, dan zie je ook in welke regel het fout is gegaan ! Gebruik voor het toevoegen van de regelnummers trouwens de Freeware MZ-tools addin voor vb (http://www.mztools.com, een aanrader voor iedere VB-programmeur), die heeft daar een optie voor.
Thnx voor deze tips, het heeft geen nut bij mijn huidg probleem, maar nuttige tips zijn het zeker.. _/-\o_
farlane schreef op 06 mei 2004 @ 09:25:
[...]

Ik zal hem simpel beantwoorden :
- locking probleem ( deadlock )
- timing pobleem
- bug
- all of the above
- none of the above
Ok,
• Locking: Doel je op een DB-locking? Ik heb namelijk geen DB-connectie, alleen Socketcommunicatie en een DCOM-Connectie.
• Timing: Ik verwacht niet dat het een timing probleem is, ik kan in andere logging zien dat de app, vlak voor en na het crashen geen data heeft ontvangen en dus niet uit had te voeren.
• bug: Dat is de kern van mijn vraag, wat voor bug kan er voor zorgen dat een app dat niets hoeft te doen kan crashen, er is geen multithreading, overal zit logging in en toch zie ik niets in de logging dat er code uitgevoerd zou worden tijdens het moment dat de app ging hangen

Nog even over de Bug, een bug kan zorgen voor een crash, een geheugen lek veroorzaken en foute functionaliteiten veroorzaken. Maar een essentieel onderdeel van een bug lijkt me toch dat er code wordt uitgevoerd en dat blijkt niet het geval te zijn.

* Tukk voelt zich n00b. :(

Q: How many geeks does it take to ruin a joke? A: You mean nerd, not geek. And not joke, but riddle. Proceed.


  • Markieman
  • Registratie: December 2001
  • Laatst online: 15-05 12:16
Tukk schreef op 07 mei 2004 @ 10:23:
Nog even over de Bug, een bug kan zorgen voor een crash, een geheugen lek veroorzaken en foute functionaliteiten veroorzaken. Maar een essentieel onderdeel van een bug lijkt me toch dat er code wordt uitgevoerd en dat blijkt niet het geval te zijn.
Een bug kan ook code zijn die uitgevoerd wordt waardoor er opeens geen code meer wordt uitgevoerd :)

Gezien het feit dat ik nog nooit problemen met een Timer heb gehad (en wat heb ik die dingen vaak gebruikt) en ik ook nog nooit van zoiets heb gehoord denk ik toch dat het aan je 3rd party OCX ligt.

Kan je hiervoor niet iets anders gebruiken, kan je desnoods niet gewoon windows-sockets ofzo gebruiken?

You do not fear them? - The Wraith? Naah. Now *clowns*, that's another story.


  • VlaFlip
  • Registratie: Februari 2000
  • Laatst online: 03-12-2025

VlaFlip

format c: , weg d'r mee!!

Service pack 6 misschien de oplossing:

http://msdn.microsoft.com...s/sp/vs6/sp6/default.aspx

zie zo in de lijst met gefixde problemen niet zo snel iets wat hierop lijkt, maar je weet maar nooit...

Geef je muis af en toe een stukkie kaas


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Waarschuwing: SP6 veroorzaakt nogal wat problemen! Zie [rml]RobIII in "[ VStudio6] Service Pack 6 komt eraan (ei..."[/rml] voor meer info.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • farlane
  • Registratie: Maart 2000
  • Laatst online: 22-05 16:53
Tukk schreef op 07 mei 2004 @ 10:23:
Ok,
• Locking: Doel je op een DB-locking? Ik heb namelijk geen DB-connectie, alleen Socketcommunicatie en een DCOM-Connectie.
:) Nee, ik bedoelde meer dat er verschillende code paden op elkaar staan te wachten. Aangezien je niet weet wat er in de OCX gebeurd, kan dat best het geval zijn.

Je vertelt dat je in je timer functie een ocx aanroep doet. In je ocx event zet je de timer uit en weer aan. Beide events zijn asynchroon aan elkaar. Is er een situatie te verzinnen waarbij terwijl je in de timer functie zit, het ocx event optreedt en dat er vervolgens iets mis gaat ?

Heb je een error handler in je beide functies die ervoor zorgen no matter what er ook gebeurd iig de timer weer aangezet wordt ?

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • Tukk
  • Registratie: Januari 2002
  • Laatst online: 12:38

Tukk

De α-man met het ẞ-brein

Topicstarter
farlane schreef op 07 mei 2004 @ 16:48:
[...]

Je vertelt dat je in je timer functie een ocx aanroep doet. In je ocx event zet je de timer uit en weer aan. Beide events zijn asynchroon aan elkaar. Is er een situatie te verzinnen waarbij terwijl je in de timer functie zit, het ocx event optreedt en dat er vervolgens iets mis gaat ?
Nee, die is er echt niet, verder ga ik er van uit dat dit op Windows-level opgelost zou moeten worden.
Heb je een error handler in je beide functies die ervoor zorgen no matter what er ook gebeurd iig de timer weer aangezet wordt ?
Jep.

*Kickje*

Ik denk wat verder te zijn gekomen, ik dacht eerst aan het feit dat VB, na de afloop van een functie zelf Objecten gaat opruimen. Mischien dat daar wat fout ging, maar er wordt echt geen object gebruikt. Het zou wel een verklaring kunnen zijn voor wat ik zie, na mijn logging geen draaiende app meer.

Wat ik nu verwacht is dat de third-party OCX nog code uitvoert omzelf dingen op te ruimen, nadat bij mij het event was afgegaan. Ik ben nu bezig om source code van deze ocx te bekomen. Ik hoop dat het daar inzit..

Q: How many geeks does it take to ruin a joke? A: You mean nerd, not geek. And not joke, but riddle. Proceed.

Pagina: 1