MacOS-64: kein StackTrace seit dem Umstieg auf die LLVM-Architektur

[philipp.hofmann]

Hi,

unter Windows nutze ich MadExcept und für Android/iOS habe ich eine Helper-Klasse, die mit einen brauchbaren StrackTrace zu allen Fehlern liefert. So kann ich bei mir noch unbekannten Fehlern mit Hilfe der Logfiles und des StackTrace meist eine Fehlerbehebung bauen und ausliefern. Nur unter MacOS fehlt mir dies seit dem Umstieg auf die 64bit-Variante jedweder StrackTrace (davor konnte man dies auch tun, dazu hatte ich hier im Forum auch den Code geteilt). Ich habe somit im Falle eines Fehlers wirklich nur ein Logfile und jetzt soll das System ja auch nicht nur mit Logging beschäftigt sein.

Aktuell suche ich einen Fehler, der definitiv in der Windows- und der iOS-Variante nicht vorkommt und der die MacOS-App auch nach 70 Minuten Laufzeit bei einem Kunden zum Absturz bringt. Bei anderen MacOS-Kunden läuft es tadellos und ich habe jetzt schon einige Testläufe mit über 3 Stunden Laufzeit auf meinem MacBook hinter mir und der Fehler ist leider nicht aufgetaucht. Wenn ich es selbst reproduzieren könnte, würde ich im Notfall das Logging temporär richtig hochdrehen und jeden Quatsch loggen, um einfach die Stelle stückweise einzukreisen. Dies funktioniert aber nicht, wenn es nur beim Kunden passiert. Dazu müsste ich von ihm x-Testläufe verlangen, was einfach nicht geht.

Wie geht ihr damit um und macht eine MacOS-64-Version eurer Software stabil?

Grüße, Philipp

[CHackbart]

Hi,

ich hatte vor geraumer Zeit so etwas ähnliches benötigt und bin über https://blog.grijjy.com gestolpert. Offiziell geht das nur für Android und iOS, aber da letzteres ja mittlerweile nahezu gleich hinsichtlich der API zu MacOS kommt, war eine Erweiterung für MacOS relativ simpel.

Der Code ist im Anhang zu finden.

Eingebunden wird das in etwa wie folgt:

Delphi-Quellcode:

procedure TfrmMain.HandleExceptionReport(const Sender: TObject;
  const M: TMessage);
var
  Report: IgoExceptionReport;
begin
  Report := TgoExceptionReportMessage(M).Report;

  { This message can be sent from any thread. So if we want to show the report
    in the UI, we need to synchronize it with the main thread. We use
    TThread.Queue here so it doesn't block. }
  TThread.Queue(nil,
    procedure
    begin
      ShowReport(Report.Report);
    end);
end;

procedure TfrmMain.FormCreate(Sender: TObject);
var
  Available: Boolean;
  AppEventSvc: IFMXApplicationEventService;
begin
  Application.OnException := TgoExceptionReporter.ExceptionHandler;
  TMessageManager.DefaultManager.SubscribeToMessage(TgoExceptionReportMessage,
    HandleExceptionReport);
..

Christian

[philipp.hofmann]

You make my day, funktioniert wunderbar.

[Rollo62]

Ich hab zwar keinen StackTrace, aber ich hatte mich vor Jahren mal mit den Instruments beschäftigt.
Da gab es eine Menge Tools, die auch verschiedene Fehler tracken konnten, hab aber seit längerem nchts mehr damit gemacht.
https://www.avanderlee.com/debugging...time-profiler/

Ja wenn die Grijjy Lösung für iOS und Mac funktioniert ist das natürlich super.

[philipp.hofmann]

Ich habe doch noch zweie Rückfragen, nach dem ich mir heute das Logfile der über den AppStore ausgelieferten Version angeschaut habe.

a) Was genau ist noch zu tun, damit das StackTrace auch die richtigen Code-Infos liefert?
Im Debug-Modus ist dies der Fall, im Release-Modus nicht. In beiden Konfiguration ist Map-File auf "Off" gestellt.
Ist schwierig zu testen, weil man dafür jedes Mal eine Auslieferung für den AppStore benötigt.
Ich habe die Compiler-Settings als Screenshot angehängt. Reicht da vielleicht "Symbol reference info" schon aus?

Im Release Modus:

Code:

TestException
At address: $00000001110A0EAD (TMethodImplementationIntercept + 16335597)

Call stack:
icTrainer                 $000000011118FD43 TMethodImplementationIntercept + 17314179
icTrainer                 $000000011001262D SignalConverter + 3405
icTrainer                 $0000000110035930 SignalConverter + 147536
icTrainer                 $000000010FFFB085 @DbgExcNotify + 357
icTrainer                 $000000010FFFB185 @DbgExcNotify + 613
icTrainer                 $00000001110A0EAD TMethodImplementationIntercept + 16335597
icTrainer                 $0000000110370160 TMethodImplementationIntercept + 2504096
icTrainer                 $00000001103E7BD9 TMethodImplementationIntercept + 2994201
icTrainer                 $0000000110435D7E TMethodImplementationIntercept + 3314110
icTrainer                 $000000011057EC6E TMethodImplementationIntercept + 4661422
icTrainer                 $000000011057F57A TMethodImplementationIntercept + 4663738
icTrainer                 $000000011056FCD3 TMethodImplementationIntercept + 4600083
icTrainer                 $00000001111AD2DF TMethodImplementationIntercept + 17434399
AppKit                    $00007FFF22E4A578 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 6482
AppKit                    $00007FFF22E48A06 -[NSWindow(NSEventRouting) sendEvent:] + 347
AppKit                    $00007FFF22E47881 -[NSApplication(NSEvent) sendEvent:] + 3021
AppKit                    $00007FFF2311FBE1 -[NSApplication _handleEvent:] + 65
AppKit                    $00007FFF22CAFC8E -[NSApplication run] + 623
icTrainer                 $00000001111AD0E2 TMethodImplementationIntercept + 17433890
icTrainer                 $000000011056B49D TMethodImplementationIntercept + 4581597

Im Debug Modus:

Code:

TestException
At address: $0000000103054C86 (Myictrainer.TicTrainerF.eLicenceKeyKeyUp(TObject*, var Word, var Char, set of Classes.System_Classes__1) + 1286)

Call stack:
icTrainer                 $00000001031A6B78 Myerrorreporting.TgoExceptionReporter.GlobalGetExceptionStackInfo(TExceptionRecord*) + 136
icTrainer                 $000000010190DC61 Sysutils.Exception.RaisingException(TExceptionRecord*) + 65
icTrainer                 $000000010193D14B Sysutils.RaiseExceptObject(TExceptionRecord*) + 59
icTrainer                 $00000001018EE425 _RaiseAtExcept(TObject*, Pointer) + 69
icTrainer                 $00000001018EE539 _RaiseExcept(TObject*) + 25
icTrainer                 $0000000103054C86 Myictrainer.TicTrainerF.eLicenceKeyKeyUp(TObject*, var Word, var Char, set of Classes.System_Classes__1) + 1286
icTrainer                 $0000000101DD0FBB Fmx.Controls.TControl.KeyUp(var Word, var Char, set of Classes.System_Classes__1) + 107
icTrainer                 $0000000101E7485E Fmx.Controls.Presentation.TPresentedControl.KeyUp(var Word, var Char, set of Classes.System_Classes__1) + 62
icTrainer                 $0000000101EDF4BD Fmx.Forms.TCommonCustomForm.KeyUp(var Word, var Char, set of Classes.System_Classes__1) + 109
icTrainer                 $00000001020ABD89 Fmx.Platform.Mac.DoKeyUp(TObject*, Fmx.Forms.TCommonCustomForm*, Word, Char, set of Classes.System_Classes__1) + 185
icTrainer                 $00000001020ACAD3 Fmx.Platform.Mac.TPlatformCocoa.KeyProc(TObject*, Fmx.Forms.TCommonCustomForm*, Macapi.Appkit.NSEvent, Boolean, Boolean) + 1283
icTrainer                 $0000000102096A23 Fmx.Platform.Mac.TFMXViewBase.keyUp(Macapi.Appkit.NSEvent) + 227
icTrainer                 $00000001031BC2DF DispatchToDelphi + 209
AppKit                    $00007FFF22E4A578 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 6482
AppKit                    $00007FFF22E48A06 -[NSWindow(NSEventRouting) sendEvent:] + 347
AppKit                    $00007FFF22E47881 -[NSApplication(NSEvent) sendEvent:] + 3021
AppKit                    $00007FFF2311FBE1 -[NSApplication _handleEvent:] + 65
AppKit                    $00007FFF22CAFC8E -[NSApplication run] + 623
icTrainer                 $00000001031BC0E2 DispatchToImport + 226
icTrainer                 $000000010208FDD8 Fmx.Platform.Mac.TPlatformCocoa.Run() + 184

b) Kann man aus der Info
icTrainer $0000000103054C86 Myictrainer.TicTrainerF.eLicenceKeyKeyUp(TObject*, var Word, var Char, set of Classes.System_Classes__1) + 1286
auch die tatsächliche Stelle im Code auslesen?

Code:

procedure TicTrainerF.eLicenceKeyKeyUp(Sender: TObject; var Key: Word; var KeyChar: Char; Shift: TShiftState);
begin
  {$IFNDEF ANDROID}
    if (lowercase(eLicenceKey.text) = 'delete') then
    begin
      testModus:=True;
      eLicenceKey.text:='';
      {$IF defined(MACOS) or defined(GOOGLE) or defined(MSWINDOWS)}
      firstRestorePurchased:=False;
        {$IFDEF MACOS}
          newestRenewLicenceDate:=0;
        {$ENDIF}
      {$ENDIF}
      System.SysUtils.deleteFile(appPathRef + TStringUtils.getLicenceFileName());
      System.SysUtils.deleteFile(appPathRef + 'icTrainer.icll');
      displayTestModusInfo();
      exit;
    end else if (lowercase(eLicenceKey.text) = 'exception') then
      raise Exception.create('TestException');
  {$ENDIF}
end;

[philipp.hofmann]

Frage (a) habe ich mir selbst durch ausprobieren und vergleichen mit der iOS-Release-Konfiguration beantwortet:

Code:

Tools - Optionen
  Building - Delphi Compiler - Linking -Debug Information: auf true setzen

Dies ist nicht zu verwechseln mit Building - Compiler - Debugging - Debug Information, dies sollte in der Release Konfiguration false bleiben.
durch dieses Settings wird die dsym-Datei auch in der Release-Konfiguration erzeugt und diese steht in der Deployment-Informationen schon mit dabei, wird also automatisch mit ausgeliefert.

[Rollo62]

Zitat von philipp.hofmann:

durch dieses Settings wird die dsym-Datei auch in der Release-Konfiguration erzeugt und diese steht in der Deployment-Informationen schon mit dabei, wird also automatisch mit ausgeliefert.

Hast Du schon einen solchen Release im Store, ohne Beanstandungen ?

Ich hatte mal einen Review (war aber iOS und schon länger her), der meckerte weil keine Debug-Versionen in den Store durften,
oder so ähnlich.
Seitdem lade ich wirklich nur echte Releases in den Store, ohne Debug-Symbole.

Ich weiss aber auch nicht inwieweit die Delphi Symbole Apple überhaupt tangieren.

[philipp.hofmann]

Ja, ist sowohl für iOS (schon ewig) als auch seit heute für MacOS so im Store. Bisher keine Bestandung, aber 7 MB größere Installationsdatei.