Page 1 of 2 1 2 LastLast
Results 1 to 15 of 18

Thread: Ramdom exception probleem

  1. #1

    Ramdom exception probleem

    Hallo,

    Ik ben bezig met een download tool, maar loop vast met hetvolgende.

    Als ik mijn queue laad, en dan mijn Queue leegmaak (clear). dan krijg ik af en toe een General Exception.
    Soms na 1000 records verwijderd, maar soms na 24000 records.
    Je kan de load queue aantal malen drukken, dan wordt the lijst langer.

    Kan iemand er is naar kijken, om te zien wat ik verkeerd doe?

    Alvast bedankt.

    ps. unzip de 2 files in dezelfde folder.
    Attached Files Attached Files

  2. #2
    Je programma runt hier niet omdat je tal van Tcx... componenten gebruikt en ik die niet heb.
    Maar je hebt vrij zeker een race condition. En na je code even doorgescand te hebben, denk dat het in de btnclearqueuemanagerClick zit. Daar bouw je een lijst met objecten die uit je tree verwijderd moeten worden. Daarna ga je voor elk item in de lijst iets doen en na 500 "hits" doe je een "processmessages" (altijd gevaarlijk). Je thread communiceert met de main thread via post messages (ook gevaarlijk) en dus zal na een "processmessages", ook je events afgaan. En als ik in WMProcessing kijk dan kan er potentieel iets gebeuren met een item in je opgebouwde lijst waardoor je lijst "ongeldige" elementen kan bevatten die dan een RTE opleveren.

    Om dit uit te sluiten, probeer je de processmessages even niet aan te roepen. Crashed het dan niet meer dan weet je zeker dat daar de uitdaging zit.

  3. #3
    Hallo.

    Bedankt, zal er is naar kijken. de Tcx componenten zijn van DevExpress. Had het miscchien beter even kunen vervangen voor een normaal Tab blad. Mijn exuses.

    Ik roep inderdaad processsmessages aan, om me teller up te daten.. anders staat het hele scherm vast en wist ik niet of er nog wel leven inzat.
    Zal er mee spelen, en als ik nog steeds vast zit, een nieuw project uploaden met de Devexpress eruit.

  4. #4
    Quote Originally Posted by trainlover View Post
    Ik roep inderdaad processsmessages aan, om me teller up te daten.. anders staat het hele scherm vast en wist ik niet of er nog wel leven inzat.
    Dat is toch juist ook een reden om iets naar een thread te verplaatsen? Daar gaat iets niet goed dan.
    1+1=b

  5. #5
    Ik heb de processmessages uitgeschakeld, en dan gaat de queue leeg, maar bij een 2e keer met 30000 records dan zijn een aantal velden maar leeg, en dan krijg ik de error.
    Zal me project aanpassen en opnieuw plaatsen.

  6. #6
    Hier is het aangepaste project, waar het kan zien.

    als je het 1 keer start, geen probleem.
    maar als je load 4-5 keer drukt zo dat je 40000 records hebt,
    dan zie je het op een gegeven moment.
    Attached Files Attached Files

  7. #7
    Probeer de code te lezen maar het is mij iets te lang om zo maar even een bug te vinden zeker als er threads worden opgebouwd om maar 1 ding te downloaden en vervolgens die thread "gewoon" weer wordt weggegooid (waarom?). Vervolgens die thread veel te veel met zijn eigenaar moet kletsen in lock mode om te vertellen wat hij aan het doen is en hoe laat hij daar mee begon, (waarom? ) en als je ver genoeg blijft zoeken in de code dat er dan als het echt nodig is geen(!!) lock gebruikt bij het make van een unieke filename als het bestand opgeslagen moet worden.... Die functie is echt niet thread safe....

    Wat is er mis met alle download urls/bestandnamen in een queue te plaatsen en desnoods met de unique file naam er al bij en die x threads gewoon die queue te laten verwerken?

    of ipv indy (blocked) ics (async) te gebruiken en het zonder threads doen en het jezelf wat makkelijker maken? Kijk als voorbeeld eens naar de HTTP Async demo code van ICS
    Last edited by Miep; 17-Mar-20 at 20:51.

  8. #8
    Ik toevoeg een exra veld, zo als de download klaar is, dan weet het wat het moet doen.
    bv "image-a" , "documents" , "archives" , "image-b"

    Misschien dat ik het verkeerd aangepakt heb, maar dit was de snelste manier, voor het geval ik 40.000 downloads in the queue heb staan.

    Maar met niet lock safe, heeft dit ook te maken dan met een queue laden en verwijderen?

  9. #9
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    En zet alle range checks aan.

  10. #10

  11. #11
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Via het project alles aanzetten. {$R+} is een lokale definitie dus geldt maar tot het eind van de unit.

  12. #12
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Via het project alles aanzetten. {$R+} is een lokale definitie dus geldt maar tot het eind van de unit.

    fastmm in fulldebug mode is ook zo'n standaard tool om mee te checken. Het detecteert met name gebruik na free en dubbele frees.

  13. #13
    Ik kan het project nog niet runnen omdat ik geen VirtualTreeView heb.

    Als ik verder naar de code kijk, dan kan het ook fout gaan in de downloadtreeAfterCellPaint routine waar gepaint wordt terwijl een tree node item dat wijst naar een download item pointer net verwijderd is in Button2Click. Het fysiek uit de tree verwijderen zal immers pas *na* de volgende message handling plaatsvinden.
    FDownloader.RemoveDownload verwijdert het Download object, en stuurt een PostMsgData dus er is een race condition dat de tree ververst nog voordat de PostMsgData is afgehandeld, wat een RTE zal opleveren.

  14. #14
    Quote Originally Posted by havezet View Post
    Ik kan het project nog niet runnen omdat ik geen VirtualTreeView heb.

    Als ik verder naar de code kijk, dan kan het ook fout gaan in de downloadtreeAfterCellPaint routine waar gepaint wordt terwijl een tree node item dat wijst naar een download item pointer net verwijderd is in Button2Click. Het fysiek uit de tree verwijderen zal immers pas *na* de volgende message handling plaatsvinden.
    FDownloader.RemoveDownload verwijdert het Download object, en stuurt een PostMsgData dus er is een race condition dat de tree ververst nog voordat de PostMsgData is afgehandeld, wat een RTE zal opleveren.
    Hallo,
    Ik denk dat je op het goede spoor zit hierzo.. dwz, als het fout gaat en ik gewoon doorga, dan is de view inderdaad door elkaar.
    Zal het is in die hoek zoeken vandaag.

  15. #15
    Helaas, de downloadtreeAfterCellPaint is niet het probleem. (die wordt alleen gebruikt voor de progressbar. ) maar aangezien niks gestart is, valt we weinig te tekenen.

    Probleem zit ergens met de FDownloader.RemoveDownload(item); opdracht. Kom er alleen niet uit.

    Had de andere suggesties ook geprobeerd om processmessages uit te zetten, maar ook hetzelfde probleem.

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •