STAX als Remote logging Tool verwenden

Rund um die LCL und andere Komponenten
Benutzeravatar
theo
Beiträge: 10467
Registriert: Mo 11. Sep 2006, 19:01

Re: STAX als Remote logging Tool verwenden

Beitrag von theo »

af0815 hat geschrieben:
Mo 4. Jul 2022, 14:07
Bezüglich Code meinst du sicher viewtopic.php?f=16&t=14015 als Beispiel.
Davon ausgehend habe ich für mich schnell eine Testanwendung gemacht, um zu schauen, ob das brauchbar ist.
Wenn du damit mal spielen möchtest: Siehe Anhang.

Code: Alles auswählen

pkill -SIGUSR1 project1
Schaltet das Logging Ein/Aus.

Code: Alles auswählen

pkill -SIGUSR2 project1
Schaltet den Verbose Modus Ein/Aus.

Wenn die Anwendung unter dem Debugger läuft, mischt der sich natürlich ein.
Deshalb ohne GDB starten (Strg+Umschalt+F9).

Diese Variante ist einfach sehr schlank und das war dir doch auch wichtig.
Dateianhänge
project1.zip
(139.95 KiB) 42-mal heruntergeladen

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: STAX als Remote logging Tool verwenden

Beitrag von af0815 »

theo hat geschrieben:
Mo 4. Jul 2022, 14:31
Diese Variante ist einfach sehr schlank und das war dir doch auch wichtig.
Danke, das ist wirklich seeeehr schlank. Erschreckend wie einfach manchmal was sein kann.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: STAX als Remote logging Tool verwenden

Beitrag von Warf »

PascalDragon hat geschrieben:
Mo 4. Jul 2022, 14:08
Das haben weder FPK und Jonas noch ich so geschrieben.
Das mag sein, aber es ist die Logische konsequenz da a. es unmöglich ist SetJmp/LongJmp cross stack frame zu verwenden ohne dabei den exception state kaputt zu machen, und b. diese funktionen die das ermöglichen nicht implementiert werden da sie zu fehlerannfällig sind (was ironisch ist, da SetJmp und LongJmp bereitgestellt werden, bei denen es unmöglich ist keinen Fehler zu produzieren, da die funktionen immer den Exception state kaputt machen. Jeder call zu Longjmp ist ein Fehler), sowie keine alternative vorgeschlagen wurde, bzw. alternativen die ich vorgeschlagen wurde, wie das integrieren der funktionalität in SetJmp/LongJmp selbst, auch abgelehnt wurden.

Ergo wenn es aktuell nicht möglich ist SetJmp/LongJmp zu verwenden, und es keine intention gibt das zu Ändern, schließe ich daraus das die Intention ist das SetJmp/Longjmp nicht benutzt werden sollen.

Klar wurde das nicht explizit gesagt, aber im endeffekt ist es das worauf es hinausläuft. Man kann SetJmp/LongJmp nicht verwenden, und es wird vermutlich dafür auch keinen Fix geben

PS: Ich versteh die Argumentation übrigens schon, Pascal ist eine High Level Sprache, die sowas wie Exceptions auf Sprachebene Abstrahiert und verschiedene Mechanismen haben kann (SetJmp/LongJmp, SEH, LLVM, etc.), und daher sowas was nicht cross plattform verfügbar ist nix zu suchen hat.
Was mich nur stört ist das trozdem SetJmp und LongJmp verfügbar sind, obwohl diese funktionen im aktuellen status komplett kaputt sind und jede anwendung zerschießen wenn man sie anfasst. M.E. wäre die Konsistente Lösung SetJmp/LongJmp einfach nicht öffentlich zugänglich zu machen und nur intern in der RTL zu benutzen (z.B. für die Exception Implementierung)
Zuletzt geändert von Warf am Mo 4. Jul 2022, 15:28, insgesamt 1-mal geändert.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: STAX als Remote logging Tool verwenden

Beitrag von af0815 »

@Warf: Ich habe mir STAX mit den Patch im fiber Verzeichnis genauer angesehen. Das ganze ist aktuell nur für 64 Bit Intel (Linux und Win) gedacht. Arm bzw. 32Bit Win bleibt aktuell aussen vor. Ist das korrekt ?
Zuletzt geändert von af0815 am Mo 4. Jul 2022, 15:26, insgesamt 2-mal geändert.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: STAX als Remote logging Tool verwenden

Beitrag von Warf »

af0815 hat geschrieben:
Mo 4. Jul 2022, 15:18
@Warf: Ich habe mir STAX mit den Patch im fiber Verzeichnis genauer angesehen. Das ganze ist aktuell nur für 64 Bit Intel (Linux und Win) gedacht. Arm bzw. 32Bit Win bleibt aktuell aussen vor. Ist das korrekt ?
Du Fragst sachen xD. Windows müsste die Architektur egal sein laufen (da hier WinAPI Fibres verwendet werden die unabhängig sind). Unter Unix systemen, wo der patch benötigt wird, ists nur x86_64, da ich absolut keine ahnung von arm assembly habe, aber theoretisch müsste nur der Stack switch angepasst werden:

Code: Alles auswählen

  // setup stack: copy current frame to new stack
  asm
  MOV StackPtr, RSP
  MOV BasePtr, RBP
  end;
  FrameSize := BasePtr - StackPtr;
  NewBasePtr := FStack + StackSize;
  NewStackPtr := NewBasePtr - FrameSize;
  Move(PByte(StackPtr)^, PByte(NewStackPtr)^, FrameSize);
  // set new stack as current stack
  asm
  MOV RSP, NewStackPtr
  MOV RBP, NewBasePtr
  end;
In https://github.com/Warfley/FPCFiber/blo ... s.pas#L197

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: STAX als Remote logging Tool verwenden

Beitrag von af0815 »

Danke für die Infos, meine Frage oben ist genaugenommen mit den Infos aus dem Merge Request beantwortet und heisst nein zu Arm. Da mein Focus auf RasPi liegt und es Produktivsysteme sind ist m,ir die Sache auch aktuell zu heiss.

Ich kann die Argumenttaion dazu von den Maintainern nachvollziehen, die im Merge Request aufgeführt wurden. Damit ist für mich mal einiges geklärt und eine Idee von Theo habe ich auch mitgenommen :-)
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: STAX als Remote logging Tool verwenden

Beitrag von Warf »

theo hat geschrieben:
Mo 4. Jul 2022, 14:31
Davon ausgehend habe ich für mich schnell eine Testanwendung gemacht, um zu schauen, ob das brauchbar ist.
Wenn du damit mal spielen möchtest: Siehe Anhang.

Code: Alles auswählen

pkill -SIGUSR1 project1
Schaltet das Logging Ein/Aus.

Code: Alles auswählen

pkill -SIGUSR2 project1
Schaltet den Verbose Modus Ein/Aus.

Wenn die Anwendung unter dem Debugger läuft, mischt der sich natürlich ein.
Deshalb ohne GDB starten (Strg+Umschalt+F9).

Diese Variante ist einfach sehr schlank und das war dir doch auch wichtig.
Mit Signalen muss man ganz schön vorsichtig sein. Z.B. dieser code:

Code: Alles auswählen

    SIGUSR1: Logging := Not Logging;
    SIGUSR2: Verbose := Not Verbose;  
Ist nicht standard konform: https://pubs.opengroup.org/onlinepubs/9 ... ignal.html
the behavior is undefined if the signal handler refers to any object [...] with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t,[...]
Static storage duration ist eine globale oder threadlocale variable (oder writable const). Also man darf den wert von variablen in Signalhändlern nicht auslesen, sondern nur in einer atomaren operation überschreiben.
Das ist hier nicht der Fall. Es wird zwar wahrscheinlich nichts schiefgehen, es ist aber dennoch kein korrekter code

Benutzeravatar
theo
Beiträge: 10467
Registriert: Mo 11. Sep 2006, 19:01

Re: STAX als Remote logging Tool verwenden

Beitrag von theo »

@Warf: Versteh ich nicht, was kann denn da schief gehen?
Wofür ist sigactionhandler sonst da?

Sonst schaltet man halt mit SIGUSR1 ein und mit SIGUSR2 aus.
Wäre das besser?
War ja auch nur eine Idee, niemand will damit ein AKW steuern. :wink:

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: STAX als Remote logging Tool verwenden

Beitrag von Warf »

Wie gesagt wahrscheinlich wird nichts schiefgehen, aber undefiniert heist halt das der Compiler und das System in so fällen theoretisch alles machen dürfte.

Was tatsächlich hier "richtiger" wäre, wäre es den Wert zu überschreiben (mit True) und danach einen neuen Signal Handler zu registrieren der dann den wert mit False überschreibt beim nächsten call. Das klingt vielleicht umständlich und unnötig, ist aber standard konform.
Oder man registriert einfach 2 Handler, einen zum einschalten und einen zum ausschalten. (Man kann übrigens auch noch viel mehr Signale als SIGUSR1 und 2 der standard stellt nur ein Mindestmaß an reservierten signalen da, aber spezifiziert das Plattformen beliebig mehr signale setzen dürfen, welche alle auf dem system erlaubt sind kann über ein C makro festgestellt werden)

Der Grund warum das so im standard steht ist eigentlich relativ einfach, der Standard will nicht unnötig einschränken wie Signale von der Plattform implementiert werden, so sachen wie, was passiert wenn mehrere Signale gequeued werden, wie die abgearbeitet werden, Z.B. bei GLIBC über Stackframes, da wird für jedes austehende signal rekursiv ein Stackframe gepusht und beim return wird dann das nächste signal abgearbeitet (das hat übrigens den sehr schönen seiteneffekt das du signalhandler von schon getriggerten signalen nicht mehr ändern kannst, da der lookup beim recursiven descent bereits gemacht wurde).
Was das auf jeden fall bedeutet ist, das du nicht unbedingt sicher sein kannst in welcher reihenfolge signale ausgeführt werden, wann sie auftauchen, und vor allem wenn signale andere signale unterbrechen (und wenn ausmaskiert sind wie sie gequeued werden).
Außerdem werden Signale richtig spaßig wenn man auf mehreren Threads arbeitet, da signale single threaded sind, aber man keine garantie hat auf welchem thread ein externes signal gefeuert wird.

Hier sollte im grunde nichts passieren können weil die anwendung single threaded ist, das auslesen atomar ist, und da sigaction benutzt wird, das signal sich nicht selbst unterbrechen kann (was bei z.B. "fpsignal" nicht unbedingt der Fall wäre, obwohl wahrscheinlich signal intern sigaction aufruft, kann es sein das es was das angeht sich anders verhält).
Aber wie gesagt, wenns um undefiniertes Verhalten geht, kann man keine garantien geben. Das gesagt, da halten sich auch nicht alle dran, wie man beim gnu disk-destroyer source schön sieht, hält sich nicht mal GNU dran:

Code: Alles auswählen

static void
siginfo_handler (int sig)
{
  if (! SA_NOCLDSTOP)
    signal (sig, siginfo_handler);
  info_signal_count++;
}

Antworten