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

Thread: AV op assertion

  1. #1
    Game-Programmer nschagen's Avatar
    Join Date
    Jun 2003
    Location
    Alkmaar
    Posts
    685

    AV op assertion

    Hoi beste NL-Delphiers

    Ik ben vandaag weer iets vaags tegen gekomen. Ik ben bezig met het testen van mijn code, en wou b.v testen of mijn assertions in de juiste momenten zouden falen en een exception zouden raisen. Nu heb ik het probleem dat er een AV verschijnt op de regel van de assertion.

    Code:
    Assert( (i >= 0) and (i < Count) ,'TNashaList.Delete - index out of bounds');
    Dan krijg ik:

    ---------------------------
    Debugger Fault Notification
    ---------------------------
    Project ******\current\Testbed.exe faulted with message: 'access violation at 0x77790f52: write of address 0x00030fe0'. Process Stopped. Use Step or Run to continue.
    ---------------------------
    OK
    ---------------------------

    Hierbij verschijnt ook de CPU window waarin de regel: push esp gemarkeerd staat in de functie nldll.rtlRaiseException. :?

    Lijkt erop dat er iets fout gaat tijdens het raisen van de Assert exception. Ik heb dit soort foutmeldingen vaker gezien, maar nu heb er eindelijk eentje die tot op zekere hoogte reproduceerbaar is.

    Wat me erg verontrust, is dat als ik een breakpoint op die regel zet, alles ineens WEL goed gaat. Lijkt dus op een probleempje met delphi ofzo. Als ik breakpoints op assert's moet zetten om ze fatsoenlijk te laten werken, heb ik dus geen *** meer aan die dingen.

    Wat moet ik hier nu mee? Ligt dit aan delphi, aan een driver, aan de hardware of doe ik zelf ergens iets fout. :?

    Alvast bedankt!

    P.S: Ik gebruik Delphi 7

    Update: De code is uitgevoert vannuit een DLL-entry point. Als ik dezelfde units in een gewoon project dump gaat alles WEL goed. Als ik een try-except rond de code in het entry-point zet, vang ik daarmee de exception van mijn assert waarna ik de AV krijg. De exception kan blijkbaar niet goed verwerkt worden zodra deze de DLL verlaat. Iemand tips??
    Last edited by nschagen; 24-Jun-08 at 22:20.
    When things don't go right, Turn left

  2. #2
    En wat doet die Count? Komt die toevallig uit een object dat je maakt in een aparte thread, of in een message handler o.i.d.?
    1+1=b

  3. #3
    Game-Programmer nschagen's Avatar
    Join Date
    Jun 2003
    Location
    Alkmaar
    Posts
    685
    Okay... hierbij dan even de context:

    Code:
    function TNashaList.Delete(i: TnaInt): TNashaListItem;
    var j: integer;
    begin
      Assert( (i >= 0) and (i < Count) ,'TNashaList.Delete - index out of bounds');
    
      OnRemove(TNashaListItem(fList[i]));         //call event before removal
      TNashaListItem(fList[i]).fList := nil;
    
      if fList.OwnsObjects then //remove duplicates when true
      begin
        j := 0;
        while j < Count do  //make sure all duplicates are destroyed
        begin
          if (fList[j] = fList[i]) and (i <> j) then
            fList.Extract(fList[j]);
          Inc(j);
        end;
      end;
    
      fList.Delete(i);
    end;
    Deze code verwijdert een item van een lijst. Als de lijst zijn objecten beheert (lijst is dan owner), dan moeten alle duplicates ook verwijderd worden. Vandaar de extra code.

    Count is het aantal items op de lijst.
    When things don't go right, Turn left

  4. #4
    En een domme vraag misschien, maar is de betreffende NashaList wel geïnstantieerd? Eigenlijk dezelfde vraag als hiervoor, maar dan voor deze list.
    1+1=b

  5. #5
    Game-Programmer nschagen's Avatar
    Join Date
    Jun 2003
    Location
    Alkmaar
    Posts
    685
    Uiteraard.... een stukje code:

    Code:
    begin
      List := TNashaList.Create(False);
      A := TMyTestClass.Create('Obj1');
      B := TMyTestClass.Create('Obj2');
      C := TMyTestClass.Create('Obj3');
    
      List.Add(A);
      List.Add(B);
      List.Add(C);
    
      //blablabla... meer code
      
      //hier word delete aangeroepen
      List.Delete(0);
      List.Delete(3);  //hier wil ik een assert
    end;
    ik denk zelf eigenlijk dat het niet zozeer met de code te maken heeft, maar met het feit dat het allemaal uitgevoert word in een entrypoint van een DLL die statisch geladen is. Ik kan me geen manier indenken om code eerder uit te laten voeren. Misschien ligt het eraan dat de debugger dan nog niet actief is, aangezien de uitvoer van de eigenlijke applicatie nog niet is gestart.

    Het werkt namelijk wel als ik deze code onder een knopje hang, of onder een FormCreate event.

    Kan iemand hier iets zinnigs over zeggen??
    When things don't go right, Turn left

  6. #6
    Game-Programmer nschagen's Avatar
    Join Date
    Jun 2003
    Location
    Alkmaar
    Posts
    685
    Het lijkt erop dat ik gelijk heb.

    Ik zal even uitleggen hoe je deze bug reproduceert:

    Stap 1: Maak een project-groep met een normale VCL-applicatie erin en een DLL project. Dan heb je dus twee projecten, waarvan er eentje (de applicatie) één unit heeft.

    Stap 2: Zet het volgende in de DLL:

    Code:
    library MijnDLL;
    
    uses
      SysUtils,
      Windows,
      Classes;
    
    {$R *.res}
    
    procedure EenRoutine; stdcall;
    begin
      Beep(1000,1000);
    end;
    
    exports EenRoutine;
    
    begin
      Assert(false,'Deze tekst wil ik zien');
    end.
    We laten hier dus een assert failen. Deze geeft een exception die blijkbaar niet goed afgevangen word door de debugger. EenRoutine is alleen nodig om ervoor te zorgen dat de DLL statisch ingeladen word.

    Stap 3: Vervolgens maken we een FormCreate event in onze applicatie, waarin we EenRoutine aanroepen. Het ziet er bij mij zo uit:

    Code:
    unit Unit1;
    
    interface
    
    uses
      Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
      Dialogs;
    
    type
      TForm1 = class(TForm)
        procedure FormCreate(Sender: TObject);
      private
        { Private declarations }
      public
        { Public declarations }
      end;
    
    procedure EenRoutine; stdcall external 'MijnDLL.dll';  
    
    var
      Form1: TForm1;
    
    implementation
    
    {$R *.dfm}
    
    procedure TForm1.FormCreate(Sender: TObject);
    begin
      EenRoutine;
    end;
    
    end.
    Stap 4: We stellen bij Run > Parameters de host van onze DLL in.

    Stap 5: Vervolgens even de hele handel opslaan en runnen. Het DLL-project moet "MijnDLL.dpr" genoemd worden.

    Ik krijg hier toch echt een AV + CPU window te zien i.p.v een EAssertionFailed. Moet ik dit aan borland melden of ligt het aan mijn PC ofzo. Ik draai trouwens Vista 32 bit met Delphi 7 (Maar dat laatste maakt volgens mij geen verschil want D2007 lijkt hetzelfde probleem te hebben).

    Wil iemand dit voor me proberen??

    Heel erg bedankt!!
    When things don't go right, Turn left

  7. #7
    Met Delphi 2007 heb je inderdaad hetzelfde probleem. In de bijlage vind je mijn testproject mocht iemand het nog willen testen.

    Je zou hem kunnen reporten bij CodeGear, het lijkt me een spannende discussie of het niet werken van een Assert bij het laden van de DLL als bug wordt ervaren.
    Attached Files Attached Files
    Marcel

  8. #8
    Game-Programmer nschagen's Avatar
    Join Date
    Jun 2003
    Location
    Alkmaar
    Posts
    685
    Als je het alleen over assertions hebt, heb je gelijk. Maar ik heb zojuist het volgende getest, met hetzelfde resultaat.

    Code:
    raise EInOutError.Create('Dit wil ik zien');
    Blijkbaar zit het probleem bij de exceptions. Aangezien een Assert ook een exception oplevert, leek het me handig om dit eens te testen. Het lijkt me zo, dat het niet werken van exceptions in DLL-entrypoints toch niet zo mooi is. Wel waard om even te rapporteren denk ik. Zal ik snel doen.
    When things don't go right, Turn left

  9. #9
    Game-Programmer nschagen's Avatar
    Join Date
    Jun 2003
    Location
    Alkmaar
    Posts
    685
    Okay.. gerapporteerd. Hoop dat ik het nu goed gedaan heb:

    http://qc.codegear.com/wc/qcmain.aspx?d=63690


    De build # is in ieder geval fout.. stom... maarjah
    When things don't go right, Turn left

  10. #10
    Dat is misschien niet zo vreemd. In een reguliere applicatie zal exception handling ook niet werken als je bijvoorbeeld in een finalization sectie zit.
    1+1=b

  11. #11
    Je hebt 'm gereport op het project Quality Central in plaats van Delphi, hopelijk pikken ze dat intern op. Of misschien moet je daar even een mailtje over sturen.
    Marcel

  12. #12
    Game-Programmer nschagen's Avatar
    Join Date
    Jun 2003
    Location
    Alkmaar
    Posts
    685
    Dat is misschien niet zo vreemd. In een reguliere applicatie zal exception handling ook niet werken als je bijvoorbeeld in een finalization sectie zit.
    Hmmm... tja... dat wist ik dus niet. Maar het lijkt me dat dit op een nettere manier afgevangen kan worden. Of niet soms?

    Je hebt 'm gereport op het project Quality Central in plaats van Delphi, hopelijk pikken ze dat intern op. Of misschien moet je daar even een mailtje over sturen.
    Whooops Ik raakte echt verdwaalt op die site, en ik zag nergens een report knop ofzo (totdat ik bij QualityCentral kwam). Even mailtje over sturen inderdaad. Maar naar welk adres???
    When things don't go right, Turn left

  13. #13
    Ja, de website is een juweeltje Maar als je QC plus download (http://www.jed-software.com/) kun je een stuk makkelijker overweg. En dan kun je ook je eigen report aanpassen en in de juiste groep plaatsen.
    Marcel

  14. #14
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Ik heb dit soort dingen ook meegemaakt. Exceptions (unit Sysutils dacht ik) werken tijdens initialisatie niet goed.

  15. #15
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Misschien applicatie object dat niet goed functioneert? Of als het niet uniek is?

    Dus het is misschien niet de exceptie zelf, maar de default handler. (die het windowtje showed)

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
  •