SIGILL bei rekursion

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • SIGILL bei rekursion

    Hallo allerseits,

    ich habe folgenden code der IMMER bei 16213 mit einem SIGILL abbricht (oder wenn ichs über Xcode starte dann den debugger dranhängt).
    warum und wie kann ich das verhindern?

    danke

    Quellcode

    1. void test(unsigned counter)
    2. {
    3. counter++;
    5. printf("counter: %i\n", counter);
    7. if (counter < (20 * 1000))
    8. {
    9. test(counter);
    10. }
    11. }
    13. test(0);
    Alles anzeigen

  • gritsch schrieb:

    ich wüsste nicht wie. es geht um CGPDFDictionaryApplyFunction

    Ich kenn die Funktion nicht, darum muss ich ein wenig raten:

    Lauf mehrfach durch und bau Dir iterativ ein Baum auf -> Wenn Du in der ApplyFunction wieder ApplyFunction aufrufen willst, mach das eben nicht, sondern speicher Dir nur das Objekt, auf dass Du die Funktion anwenden willst. So kannst Du dann iterativ (hoffentlich) ein Baum aufbauen..
    ♥C++

  • zerm schrieb:

    Lauf mehrfach durch und bau Dir iterativ ein Baum auf -> Wenn Du in der ApplyFunction wieder ApplyFunction aufrufen willst, mach das eben nicht, sondern speicher Dir nur das Objekt, auf dass Du die Funktion anwenden willst. So kannst Du dann iterativ (hoffentlich) ein Baum aufbauen..

    Wenn ich das richtig sehe, kannst Du die Rekursion in dieser Funktion nicht selber abbrechen.
    „Meine Komplikation hatte eine Komplikation.“

  • gritsch schrieb:

    ich wüsste nicht wie. es geht um CGPDFDictionaryApplyFunction

    Hmmm, wo ist denn der Zusammenhang zwischen CGPDFDictionaryApplyFunction und Rekursion? Die Callbacks werden schön nacheinander aufgerufen. Kann sein, dass intern die Enumerierung rekursiv gemacht wird, aber das weiß man nicht.

    Wenn die das rekursiv machen und keine Tiefenbegrenzung reingebaut haben (ich kann mir kein sinnvolles PDF vostellen, in dem es zu solchen Tiefen kommt), könnte es knallen, aber dann ist das doch ein klarer Fall von bugreport.apple.com, oder? Ist Dir das schon konkret passiert?

    Ach ja: In QA1419 steht, wie man zur Linkzeit oder zur Laufzeit den Stack vergrößern kann.

    Edit: Natürlich kann man sich selbst das nachbauen, aber ich halte nicht viel davon, wenn's sich vermeiden lässt. Ich kann mir gut vorstellen, dass Apple da bereits einiges für Robustheit getan hat. Wenn ich mich nicht irre, basiert letztendlich die PDF-Anzeige in Safari auch darauf, deshalb sollten die ein Interesse haben, Stack und Buffer Overflows zu vermeiden...
    Multigrad - 360°-Produktfotografie für den Mac

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von mattik ()

  • mattik schrieb:

    Natürlich kann man sich selbst das nachbauen, aber ich halte nicht viel davon, wenn's sich vermeiden lässt. Ich kann mir gut vorstellen, dass Apple da bereits einiges für Robustheit getan hat. Wenn ich mich nicht irre, basiert letztendlich die PDF-Anzeige in Safari auch darauf, deshalb sollten die ein Interesse haben, Stack und Buffer Overflows zu vermeiden...

    Sehe ich eigentlich auch so und an die Möglichkeit, den Stack zu vergrößern hatte ich auch schon gedacht. *Jetzt* weiß ich auch noch, wie das geht ;)

    Das blöde ist nur, dass Du die Größe nur raten kannst. Nach Murphys Gesetz findet der DAU immer ein PDF, das den Stack zerschießt. Bei einer iterativen Lösung kann das Programm soviel Speicher nutzen, wie da ist.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Das blöde ist nur, dass Du die Größe nur raten kannst. Nach Murphys Gesetz findet der DAU immer ein PDF, das den Stack zerschießt. Bei einer iterativen Lösung kann das Programm soviel Speicher nutzen, wie da ist.


    Naja wenn du bei jedem Rekursiven Aufruf den Stack größer machst sollte es klappen. Alternativ kann man bestimmt auch die Stacknutzung abfragen und entsprechend erweitern.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • mattik schrieb:

    gritsch schrieb:

    ich wüsste nicht wie. es geht um CGPDFDictionaryApplyFunction

    Hmmm, wo ist denn der Zusammenhang zwischen CGPDFDictionaryApplyFunction und Rekursion? Die Callbacks werden schön nacheinander aufgerufen. Kann sein, dass intern die Enumerierung rekursiv gemacht wird, aber das weiß man nicht.

    Wenn die das rekursiv machen und keine Tiefenbegrenzung reingebaut haben (ich kann mir kein sinnvolles PDF vostellen, in dem es zu solchen Tiefen kommt), könnte es knallen, aber dann ist das doch ein klarer Fall von bugreport.apple.com, oder? Ist Dir das schon konkret passiert?

    Ach ja: In QA1419 steht, wie man zur Linkzeit oder zur Laufzeit den Stack vergrößern kann.

    Edit: Natürlich kann man sich selbst das nachbauen, aber ich halte nicht viel davon, wenn's sich vermeiden lässt. Ich kann mir gut vorstellen, dass Apple da bereits einiges für Robustheit getan hat. Wenn ich mich nicht irre, basiert letztendlich die PDF-Anzeige in Safari auch darauf, deshalb sollten die ein Interesse haben, Stack und Buffer Overflows zu vermeiden...


    CGPDFDictionaryApplyFunction liefert aber wieder dictionaries die nur mit CGPDFDictionaryApplyFunction iteriert werden können.

    ich werd jetzt mal was zusammenbasteln und es dann hier hochladen.

  • Mal so ins blaue gedacht.
    Die Funktion liefert dir ein Dictionary, das nur mit der Funktion iteriert werden kann. Iteration muss aber ja nicht gleich Rekursion sein.
    Also für ein Projekt, das mit GCD umgesetzt werden kann, würde ich das initiale Disctionary in eine Work-Queue packen und dann abwickeln lassen. Die Dictionaries die dabei zurück kommen, würde ich dann als weitere Elemente in Work-Queue packen und so weiter. So wird erstens nicht rekursiv sondern iterativ alles abgearbeitet und als weiteren Vorteil könnte das via GCD ggf. gleich parallelisiert werden.
    Ohne GCD wäre das entsprechend mit Threads möglich (denen man auch eine Stack-Größe mitgeben kannst, wenn du es auf C-Ebene machst). Damit wirfst du natürlich eine Lawine von Threads an, die sich den Stack aber aus dem Heap allokieren. Trotzdem sind dem natürlich Grenzen gesetzt und man muss darauf aufpassen, dass man weder races noch dead-locks bekommt, also muss man da mit Locks und Semaphores aufpassen. Die Lawine kann natürlich am Anfang exponentiell wachsen, aber irgendwann sollten die Threads doch auch am untersten Ende angekommen sein. Die Synchronisation ist da eben nur problematisch - mit GCD sollte das einfacher sein.