Deutsch
Forum

Gefahr schlimmer Crashes wg. ProcAddr bei Callbacks, Threads

 
- Seite 1 -


Hallo IF...

Ich habs mal getestet und hoffe nichts falsch gemacht zu haben:
KompilierenMarkierenSeparieren
 $U thread.pcu = thread.
DEF @GetDlgCtrlID(1) !"USER32","GetDlgCtrlID"
DEF @ButtonClicked(1) @GetDlgCtrlID(@&(1))=-%MENUITEM
Testprogramm Timer
Profan Version 9
 $H Windows.ph
-Main----------------------------------------------------------------
Declare Timer_Busy%,Ende%
Declare TimerID&,Create%,T_Text&,Test#
WindowStyle 26
WindowTitle "Timertest PHU-60"
Window 100,100 - 370,200
cls
Let T_TEXT&=@CREATETEXT(%HWND,"",30,30,300,30)
-Menue---------------------------------------------------------------
PopUp "&Programm"
AppendMenu 108,"&Einstellungen"
AppendMenu 109,"&Ende"
Ende% = 0
Timer setzen (4x pro Sekunde, 250ms)
thread.start 1,1

WhileNot Ende%

    WaitInput

    If @MenuItem(108)

        Einstellungen

    Endif

    If @MenuItem(109)

        thread.stopall
        Ende% = 1

    Endif

Wend

End
-Proc Einstellungen

Proc Einstellungen

    Declare hD%, hA%, hB%, OK%, hTime%
    Declare hF1%, hT1%
    Clear OK%
    Dialogfenster erzeugen
    hD% = @Create("Dialog",%hWnd,"Einstellungen",%WinLeft+80,%WinTop+155,230,190)
    hF1% = @Create("Font","Arial",16,0,0,0,0)
    hT1% = @Create("Text",hD%,"Einstellungen...",10,10,220,20)
    SetFont hT1%,hF1%
    hTime% = @Create("TimeEdit", hD%, "00:00:00", 10, 35, 70, 24)
    hB% = @Create("Button",hD%,"&Nachstellen",10,120,100,28)
    hA% = @Create("Button",hD%,"&Abbrechen",120,120,100,28)

    WhileNot Ok%

        WaitInput

        If @ButtonClicked(hB%)  Nachstellen

            Ok% = 1
            Aktionen hier

        ElseIf @ButtonClicked(hA%) Abbrechen

            Ok% = 1

        ElseIf (%Key = 2) ALT+F4 bzw. schließen

            Ok% = 1

        EndIf

    EndWhile

    DeleteObject hF1%
    @DestroyWindow(hD%)

EndProc

-Prozedur die in bestimmten Zeitintervallen ausgefuehrt wird (4x pro Sekunde)

Proc thread.do

    parameters n&
    Dim Test#,1000000
    Inc Timer_Busy%
    Locate 5,5
    Print "Timer:" + @str$(Timer_Busy%) + " Durchläufe"
    Settext T_Text&,"Timer:" + @str$(Timer_Busy%) + " Durchläufe"
    Dispose Test#

EndProc


Auch hier wird das Fenster nicht richtig angezeigt!
Was bedeutet das? Werden im Hauptprogramm während ein Thread ausgeführt, überschreibt Profan intern gespeicherte Variablen zum Aufrufen von API. Je nachdem, welche Profanfunktionen im Hauptprogramm verwendet werden, ist die Gefahr mal mehr und mal weniger gegeben, sie ist aber auch (laut Roland) beim direkten Aufrufen von APIs vorhanden. Wann und ob ein Fehler auftritt, hängt vom gewählten Zeitintervall, vom Rechner und von der Programmbedienung durch den User ab.
Was bedeutet das genau?

Ein Beispiel:
Beim einem Rechner unter Windows2000 wird beim Aufruf der API RegUnloadKey ein solcher Crash verursacht und die API wird deshalb nicht korrekt ausgeführt. Daraufhin wird der Registryhive des User nicht wie geplant entladen und ist beim nächsten Start nicht mehr verfügbar => ein ganzes Userprofile ist unwiederbringlich verloren.

Ein anders Beispiel:
Das Hauptprogramm schreibt während ein Callback läuft in die Registry. Da alles ungünstig zusammentrifft, wird in einen anderen Schlüssel geschrieben und Datenj in der Registry gehen verloren!

Weitere Fragen und Anmerkungen?
 
09.09.2006  
 



 
- Seite 2 -


Hallo IF...

Mir ebenfalls - vor diesem schönen Quelltext konnte ich leider den Grund nicht finden. Kannst du dir jetzt vorstellen, warum ich unbedingt wissen wollte, ob du Timer in der PCU verwendest?
Einen Thread würde ich erst stoppen, wenn er nicht mehr gebraucht wird => kann fatal werden!

Gruß

AH
 
09.09.2006  
 



Nein kann ich nicht wirklich zumal der Timer hierbei Nebensache ist wenn es tatsächlich alle Dinge betrifft welche mit procaddr  zutun haben. Da sind Timer wohl eher in der Minderheit wenn ich bedenke wie oft eine wProc angecallt wird...

Ich will sagen, selbst wenn ich jetzt in der DLL - mal angenommen - selber die Zeit rechnen würde und statt über einen Timer ein Call auf die ProcAddr mache - dann wäre es ebenso schlimm! Das Problem selbst hat also nicht vordergründig mit den Timern zu tun.

Eine Save-Variante wäre es natürlich einfach eine Message an hwnd zu senden wenn ein Event passieren soll. Das wiederum würde aber leider die Struktur ändern.
 
09.09.2006  
 



Auch an dich: Lese dir genau durch, was ich schreibe. Das Problem hat meiner Meinung nach nichts mit anderen Callbacks zu tun!
 
09.09.2006  
 



Ich lese die Postings aller Mitglieder gleichgenau durch.

Mir fehlt aber für Deine letzte Behauptung eine Begründung...
 
09.09.2006  
 



WM_TIMER wird bei Angabe einer Adresse nicht unbedingt von der WndProc bearbeitet, das ist der Unterschied.
 
09.09.2006  
 



Die Shatter Attack nutzt das - Ich suche gleich mal den Artikel...
 
09.09.2006  
 



[quote:bf2faa3b30]WM_TIMER wird bei Angabe einer Adresse nicht unbedingt von der WndProc bearbeitet, das ist der Unterschied.[/quote:bf2faa3b30]
Hm sei mir nicht böse aber ich finde das irreführend.

Ich will sagen, selbst wenn ich jetzt in der DLL - mal angenommen - selber die Zeit rechnen würde und statt über einen Timer ein Call auf die ProcAddr mache - dann wäre es ebenso schlimm! Das Problem selbst hat also nicht vordergründig mit den Timern zu tun und auch nicht damit - ob wm_timer von der wndproc erfasst wird - zumal unklar ist inwiefern Rolands wndProc dann wiederum weiterhandelt...

Aber ich glaube hier kann uns nur Roland helfen...
 
09.09.2006  
 



EasyVent.Dll - selbe Problem... insgesammt aber sicherlich nicht unschlecht das das Thema angesprochen ist - es brennt auch mir schon lange auf der Seele - packen wirs also bei den Haxen und warten Rolands Statement ab...
 
09.09.2006  
 



[quote:ae4c1936c9=iF][quote:ae4c1936c9]WM_TIMER wird bei Angabe einer Adresse nicht unbedingt von der WndProc bearbeitet, das ist der Unterschied.[/quote:ae4c1936c9]
Hm sei mir nicht böse aber ich finde das irreführend.

Ich will sagen, selbst wenn ich jetzt in der DLL - mal angenommen - selber die Zeit rechnen würde und statt über einen Timer ein Call auf die ProcAddr mache - dann wäre es ebenso schlimm! [/quote:ae4c1936c9]
Scon ausprobiert? Ich will hoffen, wir reden nicht aneinander vorbei...

[quote:ae4c1936c9]
If you pass a non-null HWND after the specified interval has passed, a WM_TIMER message is posted to the window and the TIMERPROC parameter is ignored. The other option is passing a null HWND and a valid TIMERPROC address. In this case, after the specified time has elapsed, the HWND is ignored and the system calls your TIMERPROC function.
[/quote:ae4c1936c9]
 
09.09.2006  
 



Kann schon sein das wir aneinander vorbeireden...

vielleicht sehen wir die Problematik auch an verschiedenen Stellen...

Spielt ja keine Rolle - grundsätzlich geht es darum was passiert wenn eine XProfanprozedur nicht vom XProfan selbst - sondern von außen angerannt wird... - der Diener hierzu ist procaddr . Die Aufdröselung wie Roland das realisiert hat kann nur er uns geben - bis dato könnten alle Spekulationen im Nachhinein nichtig sein.
 
09.09.2006  
 



FALSCH!!!!!!

Nicht darum von wo sie angerannt werden, sondern wie und wo sie stehen!
Stehen Callbacks außerhalb von Profan, gibt es keine Probleme. Auch bei Callbacks innerhalb von Profan dürfte es wohl nur bei WM_TIMER große Probleme geben (bin mir da aber nicht ganz sicher).
 
09.09.2006  
 



LOL, FALSCH!!! und (bin mir da aber nicht ganz sicher). An dem Postings ist nichts falsch vertrau mir.

Nun wart doch mal Rolands Antwort ab.
 
09.09.2006  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

4.206 Betrachtungen

Unbenanntvor 0 min.
H.Brill26.01.2023
Peter Max Müller13.11.2017
iF19.07.2015
Ernst02.03.2015

Themeninformationen



Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie