OpenSUSE Leap 15.1: Funktion semop liefert Fehler, nach mehrmaligen Aufrufen

Hinweis: In dem Thema OpenSUSE Leap 15.1: Funktion semop liefert Fehler, nach mehrmaligen Aufrufen gibt es 9 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • In den beiden beigefügten C-Programmen wurde unter Verwendung von Semaphoren ein Handshake-Mechanismus in einer Schleife programmiert.

    Wenn der Schleifenzähler in beiden Programmen den Wert 32768 (= 0X7FFF) erreicht hat liefert der Aufruf von semop (...) den Wert -1 zurück,

    die globale Systemvariable errno hat dann den Wert ERANGE.


    Der Fehler ist immer reproduzierbar, er tritt auch in openSUSE 10.2 auf.


    Mit den beiden Dateien x.c.txt und y.c.txt ist der Fehler reproduzierbar.

    Vorgehensweise:


    Die beiden beigefügten Dateien x.c.txt nach x.c und

    y.c.txt nach y.c umbenennen,

    Beide Source-Code Dateien compilieren mit

    g++ -o x x.c und

    g++ -o y y.c

    zwei Terminal-Fenster öffnen, im ersten Terminal-Fenster mit ./x das eine Programm,

    im zweiten Terminal-Fenster mit ./y das andere Programm starten:


    --> Nach 32768 durchläufen liefert der Funktionsaufruf Aufruf von

    ...

    struct sembuf semaphore;

    semaphore.sem_num = semNum;

    semaphore.sem_op = op;

    semaphore.sem_flg = SEM_UNDO;

    if( semop (semid, &semaphore, 1) == -1) {

    return -1;

    }


    als Rückgabewert -1, die Variable errno hat den Wert ERANGE.


    Zugegeben: In kommerziellen Anwendungen wird es kaum vorkommen, daß sooft die Funktion semop aufgerufen wird,

    wohl aber in technischen Anwendungen, beispielsweise beim Steuern von Prozessen, etc.

    Dateien

    • x.c.txt

      (3,3 kB, 9 Mal heruntergeladen, zuletzt: )
    • y.c.txt

      (3,06 kB, 8 Mal heruntergeladen, zuletzt: )

    Für den Inhalt des Beitrages 281376 haftet ausdrücklich der jeweilige Autor: hscJH

  • Ist das eine 16-, 32- oder 64bIt-Umgebung?


    Mir scheint, das die Definition des Zählers einen ungünstige Datentyp (int) hat. INT sind ja nur 16Bit = 2^15-1 (32767), LONG INT sind 32Bit = 2^31-1 (2.147.483.647) und LONG LONG = 64Bit =2^63-1 (9,22337203685e+18)


    Siehe: https://de.wikibooks.org/wiki/…anten_und_ihre_Datentypen

    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    Für den Inhalt des Beitrages 281380 haftet ausdrücklich der jeweilige Autor: Igel1954

  • Das ist normal.

    Lies man 2 semop


    Und warum erzählst du das?

    Wie lautet deine Frage?

    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 281385 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Hallo,

    Igel1954:

    der Fehler tritt bei der 32-Bit und bei der 64-Bit-Umgebung auf.

    Beim erstmaligen Creieren einer Semaphore, in meinen Fall mit

    int semid = semget (KEY, 2, IPC_CREAT | IPC_EXCL | 0666),

    bekommt man die semid = 0 zurückgeliefert.

    Nach jedem Löschen der Sema und Neuanlegen wird die semid um 32768 (0X7FFF) hochgezählt.

    In meinem Fall tritt der Fehler auch beim Stand des Schleifenzählers von 32768 auf.

    Ich vermute, daß das damit zusammenhängt.


    Berichtigung:

    Meinst du im

    man 2 semop

    den letzten Absatz im Abschnitt BUGS ?

    Weißt du, wann der Kernel mit der Fehlerbeseitigung 2.6.11 raus kommt?


    Danke und Gruß hscJH

    Für den Inhalt des Beitrages 281386 haftet ausdrücklich der jeweilige Autor: hscJH

  • Seit gefühlten drölf Äonen kann sich kaum mehr einer an Kernel 2.6.x erinnern.

    Wir sind bei 4.x oder 5.x. Besonders tapfere wagen sich noch weiter in die Zukunft.


    Ich meinte, dass das kein Bug ist, sondern normal.

    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 281387 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Berichtigung:

    Momentan sind wir bei openSUSE LEAP 15.1 bei der Kern-Version 4.12.14-lp 151.28.52-default.

    Gemäß "man 2 semop" wird im letzter Absatz im Abschnitt BUGS eine Fehlerbeseitigung in Kernel 2.6.11 genannt.

    Der von mir genannte Fehler hat also nichts mit dem Fehler zu tun, der im openSuse-manual "man 2 semop",

    im letzten Absatz im Abschnitt BUGS beschrieben ist.

    Als "normal" würde ich das Verhalten nicht bezeichnen.

    Das wäre ja genauso, als wenn beim Auto nach einer Stunde fahrt der Motor urplötzlich ausginge.


    Gruß

    hscJH

    Für den Inhalt des Beitrages 281388 haftet ausdrücklich der jeweilige Autor: hscJH

  • Ich bin kein C++-Profi, aber ich habe in anderen Sprachen programmiert, die auch solche Datentypen wie INT, LONG INT (BIG INT), DEC, DEC FLOAT, FLOAT und DOUBLE haben.
    Eine Variable vom Datentyp INT kann doch in seinen 16 Bits nur max 32767 enthalten. Damit SEMID eine Wert größer 32767 aufnehmen kann, müsste sie mit dem Datentyp LONG INT oder sogar mit Datentyp SIGNED LONG INT definiert werden.


    Eine Vorbelegung einer 16 Bit langen Variablen ohne Vorzeichen mit -1 ergibt doch B'1111 1111 1111 1111' = X'FFFF'. Bei der nächsten Addition mit +1 ergibt das eine Überlauf und sollte einen Overflow-Error erzeugen.

    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    Für den Inhalt des Beitrages 281390 haftet ausdrücklich der jeweilige Autor: Igel1954

  • @Igel1954:

    Hallo,

    beim aktuellen openSUSE gnu-c++ Compiler ist der Datentyp "short" 16 Bit, d.h der maximale Zahlenwert beträgt 32767 (=0x7FFF) begrenzt.

    Mit dem Rückgabewert der Funktion semget vom Typ int hat das nix zu tun,

    es genügt also nicht den Rückgabewert aus der Funktion semget in eine long - Variable zu speichern.


    Der Fehler tritt im Linux-Kern auf, in der Funktion semop gibt es da wohl einen Zahlenüberlauf.

    Meine Frage:

    Weiß jemand, wie man einen Fehler im Linux-Kern mit

    https://bugzilla.opensuse.org/index.cgi meldet?

    woher bekommt man de Sourcecode zu semop?


    Danke und Gruß

    hscJH

    Für den Inhalt des Beitrages 281393 haftet ausdrücklich der jeweilige Autor: hscJH

  • Mir kommt das hier langsam alles etwas seltsam vor. Erst einmal das falsche Unterforum gewählt und, ich glaube auch nicht, das deine Fragen in einem Anfängerforum für openSUSE gut aufgehoben sind. Du bist wohl hier --> https://www.programmierer-forum.de/ oder hier --> https://www.c-plusplus.net/forum/ deutlich besser aufgehoben. Das du in diesem Forum hier Antworten auf deine Fragen erhältst, die dich zufriedenstellen, glaube ich eher nicht. Ich werde das mal noch eine Weile beobachten.

  • Ich habe geschrieben, dass du die Manpage lesen sollst.

    Ich habe nicht geschrieben, dass du nur den Abschnitt Bugs lesen sollst.


    Jede numerische Variable - wie auch immer deklariert - kann überlaufen.

    Es steht explizit in der Manpage, dass es da einige Schwierigkeiten gibt, und weshalb es keine Lösung geben kann.

    Außerdem wird explizit darauf verwiesen, dass die ganze Kiste implementierungsabhängig ist.


    Zudem ist das hier nicht das Forum um Details der Kernelprogrammierung zu debattieren, geschweige denn zu lösen.

    Wenn dir dieser Zustand so mistfällt, dann ändere das einfach und reiche einen Patch ein.

    You've got the source, Luke! Change it!

    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 281396 haftet ausdrücklich der jeweilige Autor: Berichtigung