ObjectDisposedException is niet behandeld: veilige handle is gesloten aan het einde van het programma

Ik heb een .NET 4 C# -consoletoepassing. Het haalt gegevens van onze IBM i en stuurt het naar onze internet SQL Server. Het werkt perfect totdat het stopt, krijg ik de volgende foutmelding:

System.ObjectDisposedException is niet behandeld Message = Safe handle has   is gesloten Source = mscorlib ObjectName = "" StackTrace:          op System.Runtime.InteropServices.SafeHandle.DangerousRelease ()          op System.Threading.RegisteredWaitHandleSafe.Finalize() InnerException:

Mijn programmacode is:

class Program
{
    static void Main(string[] args)
    {
        System.Console.WriteLine("Begin: " + DateTime.Now.ToString());
        SystemCodeController sc = new SystemCodeController();
        sc.SyncSystemCodes();
        ParkingTicketController pt = new ParkingTicketController();
        pt.SyncParkingTickets();
        EmailHelper.SendSuccessEmail();
        System.Console.WriteLine("End: " + DateTime.Now.ToString());
    }
}

In de console zie ik de begintijd en de eindtijd. Dus ik weet dat de laatste regel wordt uitgevoerd. Wat ben ik vergeten of niet doen wat ik zou moeten zijn?

Update: The Sync* methods pull data from the IBM into an object then uses entity framework to insert the records into the database.

public void SyncParkingTickets()
{
    ptr.ClearTable();
    ptr.InsertNewCitation(ibmI.GetAllCitations());
    ptr.SaveChanges();
}

public void InsertNewCitation(IEnumerable citations)
{
    foreach (ParkingTicket citation in citations)
    {
        InsertNewCitation(citation);
    }
}

public void InsertNewCitation(ParkingTicket citation)
{
    db.AddToParkingTickets(citation);
}

public IEnumerable GetAllCitations()
{
    SystemCodeRepository scr = new SystemCodeRepository();

   // Create SQL statement

    DataTable dt = new DataTable();
    using (iDB2Connection conn = new iDB2Connection(_connString))
    {
        using (iDB2Command cmd = new iDB2Command(sb.ToString(), conn))
        {
            conn.Open();
            using (iDB2DataAdapter da = new iDB2DataAdapter(cmd)) { da.Fill(dt); }
            conn.Close();
        }
    }

    #region Fill object from DataTable
    var citations = from i in dt.AsEnumerable()
                    select new ParkingTicket
                    {
                       //Fill object
                    };
    #endregion

    return citations;
}

Alle methoden werken op dezelfde manier.

3
Ik weet niet wat WaitHandle is, dus ik gebruik het waarschijnlijk alleen indirect.
toegevoegd de auteur Mike Wills, de bron
Wat doet de Sync * -reeks van oproepen? Kunnen we die code zien? Ik wed dat het een WaitHandle lekt.
toegevoegd de auteur user7116, de bron
Ik heb het opgespoord naar de IBM-stuurprogramma's, ik heb mijn antwoord bijgewerkt om dit weer te geven en de waarschijnlijke oplossing.
toegevoegd de auteur user7116, de bron

3 antwoord

Een klein beetje van Googelen onthult een aantal verspreide rapporten van dezelfde fout bij het gebruik van de iDB2Connection familie van databasetoegangsmethoden. IBM vertrouwt kennelijk op de .Net 1.1-afhandeling van EventHandles die is gewijzigd bij de overstap naar .Net 2.0 op basis van dit Connect-artikel .

Het lijkt erop dat de enige uitstelactie is om naar de nieuwste versie van de IBM-stuurprogramma's bij te werken (met behulp van het servicepack S21917 voor 5.3 of SI37892 voor 5.4, zoals u opmerkt).


Roept u Close() op de SafeWaitHandle voor een WaitHandle ?

WaitHandle wh = ...;

wh.SafeWaitHandle.Close();//will throw ObjectDisposedException

From MSDN:

Wanneer u een nieuwe waarde toewijst aan de eigenschap SafeWaitHandle, wordt de vorige handle gesloten wanneer het vorige SafeWaitHandle-object wordt verzameld. Sluit de handle niet handmatig, omdat dit resulteert in een ObjectDisposedException wanneer de SafeWaitHandle probeert de handle te sluiten.

7
toegevoegd
Oke ... ik gebruik 5.4 niet 5.3 voor clienttoegang. Ik download sowieso de laatste patch. Ik heb het gevoel dat dit ons sneller naar de nieuwste versie van iSeries Access zal duwen. Dat is een PITA. ALLE projecten moeten tegelijk worden geüpgraded omdat u niet meerdere versies van het stuurprogramma tegelijk kunt installeren.
toegevoegd de auteur Mike Wills, de bron
Upgraden naar mijn iSeries Access V5R4 naar SI37892 leek te hebben gewerkt. Grappig, ik dacht dat ik de nieuwste versie had.
toegevoegd de auteur Mike Wills, de bron
@ordag: eigenlijk wordt de ObjectDisposedException uit de code gegooid, meestal in een andere thread, die vertrouwt op de afgehandelde event-handle!
toegevoegd de auteur user7116, de bron
Woah, dat is een slechte implementatie. Een Dispose -methode aanroepen die resulteert in ObjectDisposedException ?!
toegevoegd de auteur ordag, de bron

Zijn enkele van uw typen Disposable ? Probeer al uw wegwerphulpmiddelen weg te gooien voordat u de applicatie afsluit.

2
toegevoegd
Dat was mijn eerste gedachte na het posten. Ik heb ervoor gezorgd dat geen van mijn code IDisposable heeft. Dat hielp niet. Ik zorg er nu voor dat elk object dat ik aanraak, .Dispose() bevat.
toegevoegd de auteur Mike Wills, de bron
Zoals ik hierboven al zei, ik weet niet wat 'WaitHandle' is, dus ik gebruik het waarschijnlijk alleen indirect
toegevoegd de auteur Mike Wills, de bron
@MikeWills: het toevoegen van IDisposable lost het probleem niet op magische wijze op met het gebruik van SafeHandle . U moet in uw code kijken voor het gebruik van SafeHandle of de daarvan afgeleide klassen. Waarschijnlijk is een fout in de code gerelateerd aan een WaitHandle.
toegevoegd de auteur user7116, de bron

I have an equal situation. The problem there is that a P/Invoke call in SafeHandle.ReleaseHandle does some magic and calls System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success), which tries to do something with the SafeHandle after it was disposed.

Het is niet jouw eigen implementatie van SafeHandle ? Anders zou u in plaats daarvan geprobeerd hebben om CriticalHandle uit te breiden.

0
toegevoegd
Nee, ik heb zoiets nog niet gedaan. Is dit een bekende bug? Is er een omweg als er is? Ik haat het om problemen te hebben bij het implementeren van deze live.
toegevoegd de auteur Mike Wills, de bron
Ik heb dezelfde fout (andere app natuurlijk). Maar nadat ik er opnieuw naar gekeken had, denk ik dat ik ongelijk had. Zie mijn bewerking hierboven.
toegevoegd de auteur ordag, de bron