Attempted to read or write protected memory

[carl-johan]

Hej!
Jag har lite strul med dotnetwrappern som smäller lite titt som tätt med AccessViolationException - Attempted to read or write protected memory.

Det är svårt att reproducera men nu tog jag mig samman och gjorde ett testprogram där det alltid smäller vid programavslut i:

"at TelldusWrapper.TelldusNETWrapper.UnmanagedImport.tdUnregisterCallback(Int32 eventId)
at TelldusWrapper.TelldusNETWrapper.Finalize()"

Jag har ett classlib med koden (finns även bifogad):

Code: Select all

    public class TellStick
    {
       
        TelldusNETWrapper m_telldusNETWrapper;
        int m_callback1;
        

        public TellStick()
        {
            m_telldusNETWrapper = new TelldusNETWrapper();
            m_callback1 = m_telldusNETWrapper.tdRegisterDeviceChangeEvent(DeviceChangeEventCallbackFunction, null);
        }


        public void Close()
        {            
            m_telldusNETWrapper.unregisterCallback(m_callback1);
            TelldusNETWrapper.tdClose();
        }


        private int DeviceChangeEventCallbackFunction(int deviceId, int changeEvent, int changeType, int callbackId, Object obj)
        {   
            return TelldusNETWrapper.TELLSTICK_SUCCESS;
        }
    }

och en Konsollapplikation med koden:

Code: Select all

class Program
    {
        static void Main(string[] args)
        {
            TellStick tellstick = new TellStick();
            tellstick.Close();
        }
    }

Man skulle kunna tro att det smäller i Close() men det smäller faktiskt senare

Mitt system:
Windows 7 64-bit SP1
Tellstick Duo Batch#2 FirmWare 5
Telldus Center 2.1.1

mvh
Carl-Johan

[krambriw]

Testa en gång med att kommentera bort

Code: Select all

m_telldusNETWrapper.unregisterCallback(m_callback1);

[carl-johan]

Ingen skillnad om jag kommenterar bort unregisterCallback. Smäller fortfarande på samma ställe.

Däremot om jag kommenterar bort anropet till tdClose() så funkar det. Det är något med tdClose som får finalize (i Telldus .NET Wrapper) att smälla som den gör.

Jag hittade källkoden till dotnet-wrappern och där ser man att tdClose anropas i destruktören. Jag anropar ju den också explicit. Kan det vara att det blir två anrop till tdClose som får det att smälla? I så fall så är det en bugg i wrappern.

Code: Select all

		~TelldusNETWrapper()
		{
			//clean up
			if (registeredEventFunctionId != -1)
			{
				UnmanagedImport.tdUnregisterCallback(registeredEventFunctionId);
			}
			if (registeredDeviceChangeEventFunctionId != -1)
			{
				UnmanagedImport.tdUnregisterCallback(registeredDeviceChangeEventFunctionId);
			}
			if (registeredRawListenerFunctionId != -1)
			{
				UnmanagedImport.tdUnregisterCallback(registeredRawListenerFunctionId);
			}
			UnmanagedImport.tdClose();	//Close the library and clean up the cache it uses.
		}

[carl-johan]

Jag gav upp att använda Telldus dotnetwrapper. Smäller titt som tätt lite överallt.

Istället kavlade jag upp ärmarna och gjorde en egen i C++/CLI utan hårresande interrop med pekare och unsafe-klasser.

Code: Select all

namespace TelldusWrapper {

	public ref class Wrapper
	{
		public:
			void Init()			{ tdInit(); }
			
			String^ GetName(int deviceId) 
			{
				char* nativeName = tdGetName(deviceId); 
				String^ managedName = gcnew String(nativeName);

				tdReleaseString(nativeName);
				return managedName;
			}

                         //...etc

mvh
Carl-Johan

[PerM]

Jag gav upp att använda Telldus dotnetwrapper. Smäller titt som tätt lite överallt.

Istället kavlade jag upp ärmarna och gjorde en egen i C++/CLI utan hårresande interrop med pekare och unsafe-klasser.

Fortfarande nöjd med den lösningen? Hur pass integrerad blir den med C#-kod, har inte provat använda C++/CLI ännu?
Vill du dela med dig av den?

Förmodligen är det problemet du beskriver ovan att Telldus .NET wrapper använder finalizern som om det vore en destructor i C++, de har inte förstått hur .NET's GC fungerar. Den måste den implementera IDisposable och befintliga koden i ~TelldusNETWrapper() måste brytas ut och anropas i Dispose( bool ).

[carl-johan]

Fortfarande nöjd med den lösningen? Hur pass integrerad blir den med C#-kod, har inte provat använda C++/CLI ännu?

Lösningen blir GRYM!!! Jag har kört/jobbat på den någon vecka nu och den smäller inte en enda gång. Fördelen med C++/CLI är att jag kan prata unmanaged/native med telldus-API:t (direkt med libbet) precis som från vilket C++-program som helst, MEN jag exponerar också managed .NET-klasser mot .NET-världen. OCH jag kan göra detta utan unsafe, stökig interop, marshalling och liknande.

Av erfarenhet kan jag säga att ger man sig in i unsafe-marshalling-träsket så har man en lång och jobbig väg att vandra...

Hur som helst! Min lösning består av två lager...

Längst ned hittar du C++/CLI-lagret som nästan ett-till-ett översätter från Telldus-API till en .NET-klass. Samtidigt så introducerar jag enums för en del konstanter och ersätter de hemska callbacken med civiliserade .NET-events. Felkoder översätts också till exceptions. Det här lagret betraktar jag som färdigt för mina ändamål. Jag har då hoppat över funktionerna som hanterar olika tellstick-enheter, som till exempel tdConnectTellStickController(). Jag skulle kunna lägga till det innan jag delar med mig...

Över det lagret hittar du ett lager skrivet i C# som vidare översätter till en objektorienterad modell som gör det ännu mer nice att använda. Anledningen att jag inte har gjort allt i C++/CLI är att det är rätt stökigt att använda. Man ska aldrig göra mer än nödvändigt i C++. Det är det här lagret som din applikation är tänkt att använda. Till exempel:

1. Enheter wrappas i en klass som heter Device som har properties som Name, Protocol osv... och metoder som TurnOn, TurnOff osv... Samma sätt med sensorer som hamnar i en klass som heter Sensor och kommandon från fjärrkontroller och liknande hamnar i klassen Command. Ett objekt av typen Device eller Sensor blir dessutom automatiskt uppdaterade, till exempel om någon släcker lampan eller en ny temperaturavläsning sker.

2. Objekt av typen Device läggs i en ReadOnlyObservableCollection<Device> vilket gör att man kan databinda direkt till det från en WPF-applikation. ÄR INTE DET HÄFTIGT? Det samma gäller Sensorer. Så ett testprogram som visar enheter och sensorer kan man nästan helt skriva i XAML. Tas en enhet bort, från till exempel Telldus Center, så tas det automagiskt bort ur sin collection också.

3. Det här lagret introducerar också .NET-events som DeviceAdded, DeviceRemoved, SensorUpdated osv...'

4. Trådbytet görs också automatiskt så att event från Telldus kommer in på den tråd du använde för att skapa wrappern. Så gör du "Tellstick myStick = new Tellstick()" från GUI-tråden så blir det på GUI-tråden som alla events rasar in. Det är ju så man vill ha det, eller hur?

5. Dubletter på temperaturavläsningar och kommandon filtreras bort. Ofta skickar ju en termometer sitt värde flera gånger som en skur. Dessa filtreras bort. Annars skull det utlösa en kaskad av GUI-uppdateringar om man använder databindningar.

Det här lagret är inte färdigt. Bland annat skulle jag vilja stoppa in metoderna TurnOn, TurnOff, Dim, Execute osv... i properties så att det går att databinda mot dem från WPF. Det är lite sådant smått och gått som återstår.

Hur pass integrerad blir den med C#-kod

Svar: du får civiliserade .NET-klasser som ser ut och uppför sig som vilka .NET-klasser som helst. Du behöver inte anropa Init()/Close() eller tänka på någon typ av uppstädning. Dessutom är allt objektorienterat, till skillnad från Telldus .NEt-wrapper. Att använda den kändes som att programmera old fashioned ANSI-C fast i C#. Du har också .NET-event tillstället för callbacks. Exceptions istället för felkoder. Enums istället för konstanter.

Vill du dela med dig av den?

Absolut! Med ett par ögon till kanske jag kan få tipps på hur den kan bli ännu bättre. Jag vill bara se över namnsättningar, kommentarer och fila till det sista. Ge mig någon vecka så delar jag med mig av koden. Påminn mig om jag glömmer...

Ett kodexempel i C# hur man använder min wrapper (Jag har inte kompilerat, utan det är mer för att illustrera...)

Code: Select all

{
   Tellstick myTellstick = new Tellstick();
   
    //Print all devices
    foreach(Device device in myTellstick.Devices)
    {
        Console.WriteLine("\nDevice name: " + device.Name);
    }

    //Rename device at index zero (assuming there is a device at index zero)
    myTellstick.Devices[0].Name = "Foo";

    //Turn on device (assuming there is a device at index zero)
    if(myTellstick.Devices[0].SupportsTurnOn == true)
    {
        myTellstick.Devices[0].TurnOn();
    }

    //No need to clean up
}

[PerM]

Mmm, kände på mig att du tänkte i de banor jag gjorde

Jag utvecklar som du kanske vet Beyond Measure och har där i stöd för 1-Wire enheter, bland mycket annat. Där använder jag P/Invoke mot Dallas/Maxim's drivrutin. Egentligen inte mitt val - jag jobbade i början tillsammans med en kille från Holland på ett opensource-ramverk för 1-Wire, och han skrev just själva kopplingen mot drivrutinen med P/Invoke. Det har fungerat - och fungerar fortfarande - bra, men är ju inte direkt mitt första val. Finner jag inte ett väldigt bra själ till att dkriva om det lagret så får det leva vidare så länge.

Jag jobbar dagligen i C++ så att då använda C++/CLI kändes nu som ett naturligt val. Så när jag såg att du redan hade gjort det blev jag glad över att det verkade fungera så som jag hade förstått det.

introducerar jag enums för en del konstanter och ersätter de hemska callbacken med civiliserade .NET-events

Helt rätt.

Jag skulle kunna lägga till det innan jag delar med mig...

Du gör som du vill, men du behöver inte göra det för min skull.

objektorienterad

+1

Man ska aldrig göra mer än nödvändigt i C++

Tja, vet som sagt inte om C++/CLI är mer bökigt än native C++, men C++ som sådant är grymt om man bara tänker igenom sina lösningar. Själv utvecklar jag dagtid till 80% i C++.

Objekt av typen Device läggs i en ReadOnlyObservableCollection<Device> vilket gör att man kan databinda direkt till det från en WPF-applikation.

Låter bra, men jag saknar nog en abstraktionsnivå mellan enheter och UI, men det är ju upp till utvecklaren av respektive applikation att avgöra hur det ska byggas upp, t.ex. med MVVM-pattern osv.

Så gör du "Tellstick myStick = new Tellstick()" från GUI-tråden så blir det på GUI-tråden som alla events rasar in. Det är ju så man vill ha det, eller hur?

Hm, får titta närmare på hur du löst det där och vad den innebär i praktiken. Vanligtvis försöker jag separera kommunikation med hårdvara från applikationslogik både kod- och trådmässigt.

Dubletter på temperaturavläsningar och kommandon filtreras bort......Annars skull det utlösa en kaskad av GUI-uppdateringar om man använder databindningar

Sant, men ibland vill man - iaf jag som programmerare - se händelser ofiltrerat, också en punkt att titta närmare på.

Det här lagret är inte färdigt.

Jag ska som du kanske förstått implementera stöd för Tellstick i BM och får jag använda det du börjat skapa så är jag villig att hjälpa till och självklart dela med mig av det som jag skriver i detta bibliotek. har du funderat på hur du vill släppa koden? Licenstyp osv. Kanske kan vi komma till någon lämplig överenskomelse (dock en diskussion vi får ta via annat medium).

//No need to clean up

Nån form av upprensning måste ju till, du har ju laddat en dll någonstans? En punkt att titta närmare på.

[PerM]

Carl-Johan?

[PerM]

C-J, passar på att lämna ett meddelande till dig här innan du svarar...

Kan vi kommunicera vi ett annat medel, än detta forum, det går ju inte ens att PM:a varandra här. Skype kanske? Mitt användarnamn där är "malmbergper". Alternativt hittar du mitt nummer längst ned på sidan för BM, se länk i signaturen.

// Per

[carl-johan]

Förlåt att det har dröjt med svaret. Jag har haft det fullt upp med annat.

Själv utvecklar jag dagtid till 80% i C++.

Jag var hård i min kritik om C++. Min aversion mot C++ är en gammal krigsskada från nittitalet. Det är lite som att kasta sten i glashus för jag använder själv C++ nästan dagligen. Det är egentligen inte språket det är fel på utan utvecklarna...

Låter bra, men jag saknar nog en abstraktionsnivå mellan enheter och UI

Det är ett medvetet designbeslut.

... det är ju upp till utvecklaren av respektive applikation att avgöra hur det ska byggas upp, t.ex. med MVVM-pattern osv.

Absolut, det är en av anledningarna jag har två lager. Vill man bygga upp det själv så kan du ju gå pang-på C++/CLI-lagret, som är en direkt 1-1-mappning mellan Telldus-API (telldus-core.h) och .NET. Den har en enda klass med de metoder du hittar som funktioner i telldus-core.h. Enda skillnaden är att det har .NET-events,

Övre lagret är uppbyggt enligt MVVM (eller snarare jag håller på och kämpar med det kvällstid). Just nu har jag ett testprogram i WPF, som står för vyn. Det övre lagret i min lösning är vymodellen. Enda bindningen mellan dem är vyns DataContext som sätts till att referera vymodellen. Sedan löses resten med databnindning. Förändringar i vymodellen propageras automatiskt till vyn. Det är bara att sätta DataContext och andropa DataBind() så är det klart (givet att man har databundit i XAML).

Du ska inte stirra dig blind på mitt kodexempel jag skickade i min förra post. Det är inte så jag använder det i min utveckling. Jag sitter ju inte och loopar mig genom devices och manuellt lägger till dem till en gui-kontroll, men man KAN göra det. Jag ska se om jag kan ge dig WPF-exempel i kväll. Som heltidsarbetande småbarnsförälder med husrenoveringar är det svårt o komma loss...

Som sagt, övre lagret är frivilligt. Däremot så finner jag det förträffligt användbart och jag tror fler skulle uppskatta det om man vill komma igång snabbt. Det tar verkligen bara fem minuter göra en nu WPF-applikation där man kan se alla sensorer eller devices. Det är buslätt.

Nån form av upprensning måste ju till, du har ju laddat en dll någonstans? En punkt att titta närmare på.

Skojar bara. Blev nog för mycket lådvin under semestern IDisposable-pattern är svaret på frågan. Jag tyckte själv det lät märkligt efter jag hade besvarat ditt inlägg o var tvungen att titta efter.

Sant, men ibland vill man - iaf jag som programmerare - se händelser ofiltrerat, också en punkt att titta närmare på.

När jag gjorde filtreringen så tänkte jag tillbaka på mina uppdrag inom hårdvarunära programmering. Sluter man en brytare från Off till on så uppstår massor av studsar innan den stabiliseras på on. Dessa tar man ju bort illa kvickt. Det samma gäller omsändningar inom datorkommunikation. Gör man en TCP-server eller klient så är man ju lyckligt ovetande om omsändningar. Det sköter stacken åt en. Det var samma tänkt jag hade här. Rasar det in tre temp-läsningar med samma timestamp så är jag ju bara intresserad av en. Däremot så loggas det som en property i klassen Sensor eftersom det get en fingervisning om hur stark signalen är.

Ni måste ju förstå historien bakom det här också. Det var aldrig tänkt att det skulle bli någon typ av API som skulle delas ut. Så lösningen är ju vriden mot mina krav. Mina krav är att jag vill kunna göra enkla saker i WPF och därifrån leka med Tellsticken. Dessutom så spikar jag på en lösning med SQL-server och ett webgränssnitt. Jo, jag vet att det finns färdiga, men det här är ett hobby-projekt jag gör för mitt eget höga nöjes skull.

mvh
Carl-Johan

[krambriw]

Rasar det in tre temp-läsningar med samma timestamp

Att filtrera tycker jag också är vettigt, ta tex UPM/ESMI sensorerna från CO, dom skickar alltid tre meddelanden varje gång dom sänder.

Tycker detta verkar kunna bli ett nytt bra (standard) api...blir nästan sugen att koppla det mot python. Använder idag "standarden" från Telldus med callbacks (i den plugin som jag gjort för EventGhost).

Vet du om WPF på något sätt har inbyggt stöd för att pusha info till klienten (ungefär som websockets)? WPF är ju intressant eftersom man kan använda det i både vanliga klienter och i IE. Men är man inte tvingad att använda IE då?


mvh

[carl-johan]

Vet du om WPF på något sätt har inbyggt stöd för att pusha info till klienten (ungefär som websockets)?

Nu känner jag att jag är ute på djupt vatten. Webb är inte mitt område. Det är därför jag gör det här hobbyprojektet. Frågan är väl egentligen om .NET stödjer websockets. WPF är ju bara den grafiska delen.

WPF är ju intressant eftersom man kan använda det i både vanliga klienter och i IE. Men är man inte tvingad att använda IE då?

En "webbifierad" WPF-komponent kallas XBAP och den ska stödjas av IE och Firefox. När jag provade förra sommaren så buggade Firefox ur men det kanske är bättre idag.

Sedan finns ju Silverlight också. Det kan jag inget om men det är väldigt likt WPF. Stöds av IE, Firefox och Chrome om jag inte minns fel.

Nu har jag bara gjort testprogram i C# /WPFför att utveckla min egen dotnetwrapper och lära mig hur tellsticken fungerar bara för att det går så himla fort att prototypa. Slänga ihop något i WPF går på några minuter.

I slutändan kommer jag nog att köra en gammal hederlig ASP.NET-lösning som jobbar mot en relationsdatabas (SQL Server). Sedan har jag en fristående process (applikation eller service) gjord i .NET som kommunicerar mellan databasen och Tellsticken. På så vis blir webappen helt ovetande och väldigt löst kopplad till tellsticken.

Anledningen till ASP.NET är det finns en trevlig modell med databindningar där också, dock inte lika trevligt som WPF, men nästan. Framför allt så blir ju ASP.NET-sidorna HTML/Java/CSS när webbservern har tuggat sig igenom dem och det stöds av alla webläsare.

mvh
Carl-Johan

[PerM]

Hej,

Som heltidsarbetande småbarnsförälder med husrenoveringar är det svårt o komma loss...

Jo tack, jag vet. Lyckligtvis har jag avklarat husrenoveringen (för denna omgång).

Baserat på det lilla jag egentligen vet om det du skapat tycker jag att det låter väligt lovande och genomtänkt. Att det är ett hoppbyprojekt ger pluspoäng av mig, det tyder på entusiasm och driv hos dig, vilket en bra utvecklare måste ha. BM började som ett hobbyprojekt för drygt fem, sex år sedan.....vem vet var du är om ett år?

Ni måste ju förstå historien bakom det här också. Det var aldrig tänkt att det skulle bli någon typ av API som skulle delas ut. Så lösningen är ju vriden mot mina krav.

Absolut och självklart! Jag tycker ändå att det låter som något som vi tillsammans kan arbeta vidare på. Även om vi kanske drar åt olika håll så har vi ju samma gemensamma hårdvara vi vill använda, och alla parter är ju intresserade av ett stabilt grund paket.

Med största sannolikhet har vi olika krav, men vi får inte låta det förhindra att vi lär av varandra - den dag man slutar lära sig ska man sluta programmera är min åsikt Jag tar gärna emot en kopia ikväll, oavsett hur 'mitt i något' du tycker att den är, kanske kan jag hjälpa dig med något?

[PerM]

Efter att ha experimenterat med C++/CLI har jag beslutat mig för att trotts allt gå på PInvoke-vägen. Anledningen är att C++/CLI kostar mer än det smakar (även om det är 'läckert') då man tar 32 vs. 64 bitar med i beräkningen. Eftersom Telldus vänligt nog installerar tellduscore.dll som både 32 och 64bitar slipper man då bry sig om det.

[carl-johan]

Hej!
Ok, nu har jag hållit mig undan i en vecka för att få det så pass ok att jag slipper skämmas (hoppas jag). Man måste ju tänka på yrkesstoltheten. Trodde ni att jag hade glömt er?

Nu återstår bara två små detalj innan jag släper det.
1. Vad sätter jag för license? Telldus Center är LGPL. Jag hittar ingen info om tellduscore.lib (som min lösning använder). Är det LGPL som gäller eller?
2. Hur gör jag för att släppa det? Skickar jag bara upp zip-filen som en attachment i den här diskussionstråden eller hur "brukar" man göra?

Anledningen är att C++/CLI kostar mer än det smakar (även om det är 'läckert') då man tar 32 vs. 64 bitar med i beräkningen. Eftersom Telldus vänligt nog installerar tellduscore.dll som både 32 och 64bitar slipper man då bry sig om det.

Så med PInvoke kan du ha "any CPU" som target och slippa släppa två versioner? Är det vad du menar? Jag tycker med det är lite irriterande men att det lätt vägs upp av att man slipper allt marshalling-trassel. Nu kommer du lindrigt undan då Telldus-libbet inte innehåller några avancerade typer. Råkar man på [out]-parametrar som är arrayer av structar med pekar till arrayer osv... gärna dubbelpekare också... så håller man sig lätt för skratt med PInvoke... Fast COM är värre än PInvoke... Vaknar fortfarande upp skrikande, svettig på natten efter mardrömmar om custom safe arrays

Fast om ett par år kommer inte 32-bitars-datorer finnas kvar så då är det inga problem längre så då vinner CLI...

I alla fall. Får jag svar på mina två frågor så skickar jag upp libbet och ett testprogram så får ni göra vad ni vill med det.

mvh
Carl-Johan