1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Linux: Vom einfachen…
  6. T…

Lösung: ...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


  1. Re: Lösung: ...

    Autor: Kein Kostverächter 22.10.21 - 16:06

    Ja, aber es sind eben Regeln, die man einhalten soll, aber von der Sprache her nicht muss. Und der Regelbruch kann im Codereview übersehen werden. Ein Compilerfehler wird nie übersehen.

    Bis die Tage,

    KK

    ----------------------------------------------------------
    Mach dir deine eigenen Götter, und unterlasse es, dich mit einer schnöden Religion zu beflecken.
    (Epikur, griech. Phil., 341-270 v.Chr.)
    ----------------------------------------------------------
    We provide AI Blockchain Cloud (ABC) enabled applications bringing Enterprise level synergies to vertically integrated business processes.

  2. Re: Lösung: ...

    Autor: ultim 22.10.21 - 16:19

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > So, pass mal auf, Du Spezialist:
    >
    > Das C++-File das den Callback-Thunk aufruft und den C++-Callback enthält:
    > pastebin.com
    > Der C Callback-Thunk:
    > pastebin.com
    >
    > Und was passiert:
    > Keine Ausgabe weil terminate() aufgerufen wird, was meinen
    > Terminate-Handler aufruft der "terminate" ausgibt.
    > Interprozedurale / globale Optimierung hab ich ausschalten müssen, denn der
    > hat mir doch glatt das noinline ignoriert, dass das das Callback am Thunk
    > vorbei direkt ausgeführt wurde.

    He, Meister! Als ob wir das nicht besprochen hätten dass es von der konkreten Implementierung abhängt. D.h. dein Test hat überhaupt keine Aussagekraft bis du nicht hinschreibst welches Platform und welcher Compiler das war, und je nach Compiler mit welchen Switches der Compiler selbst kompiliert wurde.

    Du hast mal wieder etwas nur hingeworfen ohne genau darüber nachzudenken oder was klares zu sagen. Aber was ich basierend auf den aktuellen Informationsstand vermute ist, dass du auf einem Linux-Platform bist, wo fast immer DWARF-2 EH verwendet wird (das wäre das EH-Mechanismus was deiner Meinung nach gar nicht existiert, LOL), und DWARF-EH ist eben diese eine Implementierung von den 3 verbreiteten, die das Propagieren von C++-Exceptions über C-Kod nicht unterstützt.



    1 mal bearbeitet, zuletzt am 22.10.21 16:21 durch ultim.

  3. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 17:56

    > He, Meister! Als ob wir das nicht besprochen hätten dass es von der
    > konkreten Implementierung abhängt. ...

    Nein, es hängt nicht von der Implementierung ab weil es keinen C-Compiler gibt der für C++-Code Unwind-Handler generiert - wozu auch, C-Code hat nichts zu unwinden.
    Du sagtest aber, dass das per-se geht, und wenn das so wäre, dann müsste das spezifiziert sein und keine Frage der Implementation sein.

    > D.h. dein Test hat überhaupt keine Aussagekraft bis du nicht hinschreibst
    > welches Platform und welcher Compiler das war, ...

    Mein Gott, Du bist echt so ein Mega-Dampfplauderer.

    > Du hast mal wieder etwas nur hingeworfen ohne genau darüber nachzudenken ...

    Ich nicht, aber deine Antwort macht den klaren Eindruck, dass Du nicht nachdenkst.

    > Aber was ich basierend auf den aktuellen Informationsstand vermute ist,
    > dass du auf einem Linux-Platform bist, wo fast immer DWARF-2 EH verwendet
    > wird (das wäre das EH-Mechanismus was deiner Meinung nach gar nicht
    > existiert, LOL), ...

    Was redest Du da für einen Unsinn. Das Thema hat mit DWARF nichts zu tun.
    Das Problem ist, dass Du nicht vestehst wie die Unwinding-Logik von C++ bzw. die zwei möglichen Implementationen aussehen. Dass Du trotz meiner Eklärungen munter wirres Zeug redest, da kann man schon praktisch ausschließen, dass Du was komplexeres wie Embedded-Entwicklung machst.

    > ... und DWARF-EH ist eben diese eine Implementierung von den 3
    > verbreiteten, die das Propagieren von C++-Exceptions über C-Kod
    > nicht unterstützt.

    Nochmal, das hängt nicht mit DWARF zusammen, sondern für den Fall der moderneren Implementation, dass der C-Code eine Tabellen für das table-driven EH generiert. Für den Fall der älteren Impelementation, wie sie z.B. Win32 x86 Prozesse oder 32 Bit Linux Prozesse nutzen, wird das Stackframe des C-Codes tatsächlich übergangen und man landet direkt in der die C Thunk-Funktion aufrufenden C++-Funktion; das Dumme in dem Fall ist aber, dass Resourcen die die C-Funktion vor dem Aufruf des C++-Callbacks allokiert werden nicht wieder freigegeben werden, was das Ganze komplett inpraktikabel macht. Aber wie dem auch sei: auch wenn man die alte Implementation nutzt und eine C-Funktion hat die vorher keine Resourcen allokiert hat - das Verhalten ist einem nicht garantiert bzw. man darf Exceptions wirklich gesicherterweise durch C-Funktionen werfen.

  4. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 17:58

    Kein Kostverächter schrieb:
    --------------------------------------------------------------------------------
    > Ja, aber es sind eben Regeln, die man einhalten soll, aber von der Sprache
    > her nicht muss. Und der Regelbruch kann im Codereview übersehen werden.

    Die Sache ist: wenn Du auf einer modernen 64-Bit-Plattform eine Exception durch eine C-Funktion versuchst zu werfen, dann macht's terminate() - das kann man nicht übersehen. Entweder man löst das Problem, dass das Programm wieder läuft oder man hört auf zu programmieren.

  5. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 17:59

    > Natürlich ist shared_ptr ein manueller Weg.

    Manuell ist hier relativ. Es ist eben deutlich weniger manuell als in C.

  6. Re: Lösung: ...

    Autor: oleid 23.10.21 - 09:06

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > > Richtig, du hast mein Argument verstanden. Bei Rust machst du das genau
    > so.
    > > Warum disqualifiziert sich Rust jetzt?
    >
    > Weil die aus nicht nachvollziehbaren Gründen auf den system-allocator
    > gewechselt sind.
    >
    > > Natürlich liest man die papers, aber die sind nicht gerade neu ...
    >
    > So ein Quatsch. mimalloc ist weniger als 1 Jahr alt.
    >
    > > ... und glibc ist auch nicht stehen geblieben.
    >
    > Du redest von Dingen von denen Du nichts genaues weißt.

    Stimmt, die haben nix gemacht
    https://www.phoronix.com/scan.php?page=news_item&px=glibc-malloc-thread-cache


    > Die Sache ist
    > einfach, dass der glibc-Allokator aus Gründen des Speicher-Sparens relativ
    > konservativ ist und dementsprechend die Performance mittelmäßig ist.

    Genau, und auch wenig Verwaltungsoverhead hat und das genau in bester Anwendung den Ausschlag gibt.

    >
    > > Zudem: praktische Benchmarks sind äußerst anwendungsspezifisch.
    > > Was ich halt schrieb.
    >
    > Lies z.B. mal was zu mimalloc: github.com
    > Der glibc-Allocator schneidet da als einer der schlechteren ab.

    Das bestreite ich nicht, aber es geht um deren Benchmarks. In meinen Benchmarks in unserem proprietären Code ist der allocator von glibc halt am besten. Was ist daran schwer zu verstehen?

    Das ist ein bisschen so wie mit Leuten im gentoo-Forum die sich darüber streiten welches die 'schnellsten' Compilerflags sind. Muss man halt benchmarken.

  7. Re: Lösung: ...

    Autor: spiegelneuron 23.10.21 - 15:04

    > Stimmt, die haben nix gemacht
    > www.phoronix.com

    Inwiefern sich das thread caching der glibc von mimalloc unterscheidet, davon weißt Du nichts. Erstens sind die Pools bei der glibc kleiner damit auch schmalspurigere Geräte keine Probleme kriegen, zweitens haben die Pools innerhalb der Caches keine exponentielle, sondern eine lineare Größen-Verteilung - das macht _immer_ eine geringere Performance - ohne Ausnahme.

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Wissenschaftliche Mitarbeiter (m/w/d) Schwerpunkt Aufbau digitaler Programmierungs-Lerneinheiten
    Technische Hochschule Ingolstadt, Ingolstadt
  2. Business Process Expert (m/w/d)
    Richter-Helm BioLogics GmbH & Co. KG, Bovenau
  3. IT-Projektleiter (m/w/d)
    GRUNER AG, Wehingen
  4. Junior Softwareentwickler Java (w/m/x)
    über grinnberg GmbH, Raum Frankfurt am Main

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 12,99€
  2. 39,99€
  3. 12,49€
  4. (u.a. Cities Skylines Deluxe Edition für 8,99€, Cities Skylines Airport für 11,69€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Dataport: Die Arbeit wird uns nicht so schnell ausgehen
Dataport
"Die Arbeit wird uns nicht so schnell ausgehen"

Ein Job mit Zukunft und Sinnhaftigkeit, sicherer Bezahlung und verlässlichen Arbeitsbedingungen - so hat es Dataport zum Top-IT-Arbeitgeber geschafft.
Von Sebastian Grüner

  1. Arbeiten bei SAP Nur die Gassi-App geht grad nicht
  2. Merck Von der Apotheke zum zweitbesten IT-Arbeitgeber

Activision Blizzard: Was passiert mit Call of Duty, Diablo und Xbox Game Pass?
Activision Blizzard
Was passiert mit Call of Duty, Diablo und Xbox Game Pass?

Playstation als Verlierer und Exklusivspiele für den Xbox Game Pass: Golem.de über die bislang größte Übernahme durch Microsoft.
Eine Analyse von Peter Steinlechner

  1. Microsoft Sony äußert sich zur Übernahme von Activision Blizzard
  2. Spielebranche Microsoft will Activision Blizzard übernehmen
  3. Activision Blizzard Doug Bowser versus Bobby Kotick

Xbox Cloud Gaming: Wenn ich groß bin, möchte ich gerne Netflix werden
Xbox Cloud Gaming
Wenn ich groß bin, möchte ich gerne Netflix werden

Call of Duty, Fallout oder Halo: Neue Spiele bequem am Business-Laptop via Stream zocken, klingt zu gut, um wahr zu sein. Ist auch nicht wahr.
Ein Erfahrungsbericht von Benjamin Sterbenz