2015-07-02 8 views
13

Die Xamarin debugging documentation zeigt:Verwenden LLDB zu debuggen nativen Bibliotheken mit Xamarin

Use Xamarin Studio's native debugging support for debugging C# and other managed languages code and use LLDB when you need to debug C, C++ or Objective C codethat you might be linking with your Xamarin.iOS project.

Allerdings finde ich keine Dokumentation darüber, wie LLDB verwenden, um eine Xamarin App zu debuggen. Wenn ich meine App im iPhone Simulator laufen und versuchen, es zu befestigen LLDB ich mit dem folgenden Fehler:

(lldb) attach --pid 37993 
Process 37993 exited with status = -1 (0xffffffff) lost connection 

error: attach failed: lost connection 

Anbringen mit Xcode ist entweder nicht funktionieren. Ich habe verschiedene Varianten von attach ausprobiert, aber keiner von ihnen hat funktioniert.

Kann mir jemand in die richtige Richtung zeigen, wie man Xamarin-Apps mit LLDB debuggt? Kann ich das auch auf dem Gerät und nicht nur im Simulator tun? Ich habe keine Informationen darüber gefunden, wie Sie LLDB verwenden können, um eine Verbindung zu einem Prozess auf einem Gerät herzustellen.

aktualisieren

Es sieht aus wie der debugserver Prozess abstürzt, wenn ich lldb verwenden, um meine binär zu verbinden. Hier ist ein Link zu der Absturzbericht für debugserver: https://www.dropbox.com/s/9lizhl2quj9n0cc/debugserver_2015-07-07-131423_gauss.crash?dl=0

Update 2

Als ich dtruss auf der App führen Sie es druckt das System Anrufe, bis es trifft

dtrace: error on enabled probe ID 2475 (ID 194: syscall::ptrace:return): invalid user access in action #5 at DIF offset 0

die passiert, wenn etwas ruft ptrace(PT_DENY_ATTACH, 0, 0, 0); Warum wird PT_DENY_ATTACH aufgerufen?

Update 3

Ich verfolgte das ptrace System Aufruf dieser Funktion: mono_assembly_init_with_opt, die im Leben des Programms sehr früh geschieht. Diese Funktion ruft nur ptrace auf, wenn ich also gerade von dieser Funktion zurückkomme, kann ich mit lldb debuggen.

Grundsätzlich kann ich tun:

(lldb) process attach --name AppName --waitfor 
# when the process starts 
(lldb) b mono_assembly_init_with_opt  
(lldb) c 
# when the thread breaks 
(lldb) thread return 0 
(lldb) c 

und jetzt kann ich glücklich mit LLDB debuggen.

Aber ich sollte das nicht tun müssen. Ist etwas falsch mit meiner Projektkonfiguration (Ich kann einfachere Anwendungen mit lldb debuggen) oder ist Xamarin böse?

+0

Anbringen LLDB sollte die pid arbeiten, ich tue es die ganze Zeit. Sind Sie sicher, dass Sie das richtige Pid verwenden? Wo hast du es her? –

+0

Von Xcode. Debug -> An Prozess anhängen -> Wahrscheinliche Ziele listet meine App und ihre PID auf. ps auxwww | Grep App gibt mir die gleiche Pid. Muss die App in einem bestimmten Zustand sein? –

+0

Ich bin fast 100% sicher, dass Sie versuchen, die falsche PID zu debuggen. Kannst du die volle 'ps auxwww | zeigen? grep App-Ausgabe, deren Pid du anhängen willst? –

Antwort

0

Dies ist eine Einschränkung, die von Xamarin in der Testversion auferlegt wird. Nach dem Upgrade auf eine kostenpflichtige Lizenz ist dies kein Problem mehr. Auch wenn Xamarin Webseite sagt:

When you begin a Xamarin Trial, you get access to the full Xamarin Business feature set for 30 days.

Es ist eindeutig nicht der volle Funktionsumfang, da sie explizit LLDB an die App Anbringen deaktivieren, wenn Sie eine native Bibliothek verwenden. Ich bin mir nicht sicher, warum, vielleicht kann jemand von Xamarin das kommentieren.

Erklärung

Dank Jim Ingham für mich in der richtigen Richtung. Die Art und Weise, wie Debugger für Xamarin-Ereignisse mit der App verknüpft werden, besteht darin, ptrace mit PT_DENY_ATTACH aufzurufen. Dieser Systemaufruf ermöglicht es dem Prozess, Anforderungen für das Debugging zu verweigern. (Detailed Explanation).

Darüber hinaus versucht Xamarin, anstatt den Aufruf der ptrace-Funktion direkt, den Anruf mithilfe der syscall-Methode (link) zu verbergen.

Umgehung

Wenn Sie wirklich Ihre Anwendung müssen debuggen und sind immer noch mit der Testversion ist hier eine Abhilfe. Der Aufruf des ptrace-Systems erfolgt in der Funktion mono_assembly_init_with_opt, die sehr früh in der Laufzeit des Programms erfolgt. Diese Funktion macht nichts anderes und kann übersprungen werden. Da die Funktion direkt am Anfang des Prozesses aufgerufen wird, müssen wir lldb anhängen, bevor die Funktion aufgerufen wird.

Die Schritte sind wie folgt:

  1. starten LLDB und warten, bis die App zu starten.
  2. Wenn die App gestartet wird, einen Haltepunkt für mono_assembly_init_with_opt
  3. Fortsetzen der App hinzufügen, und wenn es zu dieser Funktion stoppt, kehrt früh ohne diese Funktion ausführt.
  4. Danach können Sie lldb verwenden oder Xcode an die App anhängen und Ihren nativen Code wie gewohnt debuggen.

Schritte in LLDB:

(lldb) process attach --name AppName --waitfor 
(lldb) b mono_assembly_init_with_opt  
(lldb) c 
# when the thread breaks 
(lldb) thread return 0 
(lldb) c 
1

Haben Sie versucht, die PID aus dem Activity Monitor zu verwenden? Geben Sie Ihren App-Namen in das Suchfeld im Aktivitätsmonitor ein, wenn Sie ihn in Debug ausführen.

Wenn es immer noch nicht funktioniert, können Sie versuchen, einfach ein neues Projekt zu erstellen und anfügen, nur um eine Projektkonfiguration auszuschließen.

+0

Die PID im Aktivitätsmonitor ist die gleiche wie die, die ich mit ps bekomme. Ich habe jedoch versucht, ein neues leeres Projekt zu erstellen, und ich kann mit lldb an diese App anhängen. Also, was könnte mit meiner Projektkonfiguration falsch sein? –

2

Codesignierte Apps unter Mac OS X können nur debuggt werden, wenn sie in ihrer App ein bestimmtes Attribut festgelegt haben. Sie wollen etwas, das wie folgt aussieht:

<key>SecTaskAccess</key> 
<array> 
    <string>allowed</string> 
    <string>debug</string> 
</array> 

Sie auf der man-Seite für taskgated für eine etwas knappe Beschreibung dieses Prozesses aussehen kann.

Normalerweise wird dieses Attribut bei Xcode-Projekten durch Xcode in Ihre Debug-Builds eingefügt und eingefügt, sodass Sie nichts unternehmen müssen, um dies zu erreichen.

Ich weiß nicht, wie Xamarin funktioniert, aber es ist möglich, dass es dieses Attribut nicht setzt. Auf älteren OS X-Systemen kann root alles debuggen, so dass Sie sudo -s ausprobieren und dann von dort debuggen können. Aber beginnend mit Yosemite wird die Anfrage, nicht zu debuggen, breiter geehrt ...

+0

Danke. Das ist interessant, aber es hat nicht funktioniert. Ich erhalte den gleichen Verbindungsfehler, nachdem ich die Datei Info.plist geändert habe. Das Debuggen als root hat den gleichen Fehler. –

+1

Sehr seltsam. lldb verwendet einen Debug-Agenten (debugserver genannt), der das zu debuggende Programm verwaltet. Versuchen Sie, eine fehlgeschlagene Debugsitzung auszuführen, suchen Sie dann im Systemprotokoll in Console.app nach dem Debugserver. Sie sollten einige Log-Ausgaben von debugserver sehen, und oft, wenn es Sicherheitsprobleme von den anderen Daemons (normalerweise taskgated) gibt, die für das Durchsetzen dieser Richtlinien verantwortlich sind, wird es einige Logs von ihnen ungefähr zur gleichen Zeit geben. Dort könnte etwas sein, das einen Hinweis darauf gibt, was falsch läuft. –

+0

debugserver stürzt ab, wenn ich mich mit dem Prozess verbinde. Link zum Absturzbericht: https://www.dropbox.com/s/9lizhl2quj9n0cc/debugserver_2015-07-07-131423_gauss.crash?dl=0 –