Ankündigung

Einklappen
Keine Ankündigung bisher.

Exception ohne StackFrame finden

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Exception ohne StackFrame finden

    Hallo,

    Ich steh' grade vor einem blöden Problem - in einer Anwendung, bestehend aus 6 umfangreichen OS-Apps plus einer umfangreichen Eigenentwicklung logged mir PHP ziemlich häufig Exceptions ohne StackFrame (Unknown Line 0).
    Da es sich um deutlich über 1.000 Dateien handelt und eben auch der Großteil fertige OS-Lösungen sind sitz ich nun doof da und finde das Problem nicht.
    Offensichtlich passiert das an einer Stelle, an der es an sich nichts ausmacht, es läuft alles mit tausenden Benutzern vollkommen problemlos, dennoch stört es mich gewaltig.
    Das Problem tritt, soweit erkennbar, nur auf dem Produktivsystem (Linux) auf, in meinen Testumgebungen (Win/Linux) gab's nie derartige Logeinträge.

    Hat jemand irgendeine Idee, wie ich an weitere Infos zu dem Fehler kommen könnte?
    Ein try/catch um alles ist nicht möglich, da es dafür eindeutig zu viele Einstiegspunkte/Dispatcher gibt.

    Danke im Voraus für jeden noch so kleinen Denkanstoß!
    VokeIT GmbH & Co. KG - VokeIT-oss @ github


  • #2
    Gleiche Software installiert / Andere Webserver? / 64/32bit
    Kann u.A. auch daran liegen, dass es irgendeine Anwendung nicht findet und dann eben auf eine andere Zurückgreift, deswegen entstehen keine Komplikationen beim benutzen

    Sont hab ich keine Ahnung worans liegen könnte

    Mfg

    Kommentar


    • #3
      Webserver ist jeweils der Apache, es gibt allerdings bei den verwendeten Versionen Unterschiede, die ich auch nicht ändern kann.
      Die Apps greifen nicht ineinander, die sind laufen nur parallel im gleichen Account und somit in die gleiche Logdatei.
      Trennen kann ich sie allerdings auch nicht.

      Ich werd's mal noch ein paar Tage beobachten, vielleicht lässt sich ja doch noch mal ein Muster erkennen, mit dem man es halbwegs eingrenzen kann.
      VokeIT GmbH & Co. KG - VokeIT-oss @ github

      Kommentar


      • #4
        (Unknown Line 0)
        War das nicht meist die Meldung, wenn Exceptions in Zusammenhang mit Destruktoren auftreten?
        --

        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


        --

        Kommentar


        • #5
          Zitat von nikosch Beitrag anzeigen
          War das nicht meist die Meldung, wenn Exceptions in Zusammenhang mit Destruktoren auftreten?
          Das hatte ich auch schon gelesen und hab bereits alle Destruktoren geprüft und ein try/catch um den darin enthaltenen Code gepackt - ohne Erfolg.
          Meine nächste Vermutung wäre dann ein Problem beim Serialisieren gewesen, das kann aber an so vielen Stellen passieren dass ich da die Suche gar nicht erst begonnen habe.
          Falls es interessiert: es geht um Forensoftware - da ist die Code-Qualität leider teilweise mehr als unterirdisch :-/
          VokeIT GmbH & Co. KG - VokeIT-oss @ github

          Kommentar


          • #6
            Mit einer Kombination aus auto_prepend_file und error_log könntest du ohne änderungen am code der systeme mittels einem prepend-script in verschiedene logs loggen lassen, sprich in dem prepend-script setzt du anhand von Variablen aus $_SERVER eine spezifische log-datei, damit wäre es zumindest einfacher das Problem einzukreisen.

            Nächster Ansatz wäre der Versuch über einen exception_handler erstellt im prepend-script zu schauen ob sich die exception fangen lässt und sich irgendwie loggen lässt.

            Da das logging nach einsetzen der destruktoren-aufrufe passiert und sich schlecht "testen" lässt, ist es wichtig hier mit möglichst wenig abhängigkeiten zu arbeiten, direkt absolute pfade (-> PHP: Constructors and Destructors - Manual [ The working directory in the script shutdown phase can be different with some SAPIs (e.g. Apache). ]) möglichst keine anderen klassen etc.
            robo47.net - Blog, Codeschnipsel und mehr
            | Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

            Kommentar


            • #7
              Klingt nach prepend/append Skriptausführung.
              "Mein Name ist Lohse, ich kaufe hier ein."

              Kommentar


              • #8
                Gibt debug_backtrace nichts zurück?

                Kommentar


                • #9
                  Es gibt ja bestimmte Funktionen die von PHP selbst ausgeführt werden, Destructor oder prepend/append-Skripte. Die haben keinen Backtrace (welchen auch?) und häufig auch noch Zeile 0 als Ortsangabe der $_SERVER["SCRIPT_FILENAME"].
                  "Mein Name ist Lohse, ich kaufe hier ein."

                  Kommentar


                  • #10
                    Die Idee mit der PrependFile ist schonmal gut, ich werde das mal an den Admin weiterleiten, ob er das für mich einrichten möchte.
                    Was ich auch noch testen könnte wäre, ob ich mit Pre-/Append nicht sogar einen try/catch hinbekomme, der direkt loggen kann.
                    Evtl. bekomme ich da dann auch einen Backtrace.

                    Danke für alle bisherigen Antworten!
                    VokeIT GmbH & Co. KG - VokeIT-oss @ github

                    Kommentar


                    • #11
                      Zitat von G.Schuster Beitrag anzeigen
                      Die Idee mit der PrependFile ist schonmal gut, ich werde das mal an den Admin weiterleiten, ob er das für mich einrichten möchte.
                      Was ich auch noch testen könnte wäre, ob ich mit Pre-/Append nicht sogar einen try/catch hinbekomme, der direkt loggen kann.
                      Evtl. bekomme ich da dann auch einen Backtrace.

                      Danke für alle bisherigen Antworten!
                      Soweit ich weis geht try/catch nicht datei-übergreifend, also man kann nicht try im prepend und catch im append unterbringen, weil ja jede datei für sich vom interpreter interpretierbar sein muss und mit nem offenen try ist das wohl nicht möglich, daher ja der ansatz mit dem exception-handler.
                      robo47.net - Blog, Codeschnipsel und mehr
                      | Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

                      Kommentar


                      • #12
                        Das wäre auch einigermaßen gruselig für jegliche Code-Analyse.
                        --

                        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                        --

                        Kommentar

                        Lädt...
                        X