seeseekey.net - Invictus Deus Ex Machina

Wenn man unter Java­Script ent­wi­ckelt so benutzt man sicher auch fol­gende Zeile ab und an in abge­wan­del­ter Form:

alert("XYZ");

Das Pro­blem an „alert“ ist das es für viele Sachen unprak­ti­ka­bel ist. Schö­ner wäre hier eine Kon­sole in die man diese Mel­dun­gen hin­ein­schrei­ben könnte und die auch brow­ser­un­ab­hän­gig funk­tio­niert. Genau hier kommt Black­bird ins Spiel wel­ches unter http://www.gscottolson.com/blackbirdjs/ zu fin­den ist.

Black­bird im Einsatz.

Mit der Kon­sole ist es mög­lich ver­schie­dene Log­le­vel zu rea­li­sie­ren und das ganze ein­fach in das Pro­jekt sei­ner Wahl ein­zu­bin­den. Der wei­tere Vor­teil ist, das man die Debug­mel­dun­gen im Gegen­satz zu einem „alert“ auch ein­fach im Quell­text ste­hen las­sen kann und die Aus­gabe nur bei Bedarf aktiviert.

Für die Webent­wick­lung ist es manch­mal ganz Hilf­reich die Struk­tur der Web­seite, also die ver­schach­tel­ten Tags über­sicht­lich visua­li­siert zu bekom­men. Dabei ist das Fire­fox AddOn „Tilt“ sehr hilf­reich. Die­ses stellt die Ver­schach­te­lung der Seite als 3D Modell (mit Hilfe von WebGL) dar, im wel­chem man dann die Ele­mente unter­su­chen kann.

Zu fin­den ist das AddOn unter https://addons.mozilla.org/en-US/firefox/addon/tilt/.

Manch­mal kann einen die Soft­ware­ent­wick­lung schon in den Wahn­sinn trei­ben, vor allem wenn es um tri­viale Dinge geht. So sollte es ja eigent­lich selbst­ver­ständ­lich sein, das der Debug­ger an einem Hal­te­punkt hält. Mein ers­ter Gedanke war, das es daran liegt das ich das Pro­jekt im Debug­mo­dus auf „Any CPU“ ein­ge­stellt habe. Sobald ich es auf „x86“ oder „x64“ gestellt habe, hielt der Debug­ger an der gewünsch­ten Stelle. Aller­dings hatte ich ein ähn­li­ches Pro­jekt mit fast den sel­ben Ein­stel­lun­gen (auch „Any CPU“), doch dort funk­tio­nierte es mit dem Debug­ger. Also sollte es ein Ver­gleich der Pro­jekt­da­teien rich­ten. Nach eini­ger Zeit war hier auch kein Erfolg zu melden.

Beim Star­ten des Pro­jek­tes fiel mir aller­dings auf das die Hal­te­punkte aus­ge­blen­det wurden:

Im Tool­tip zu den Hal­te­punk­ten stand dann:

No sym­bols have been loa­ded for this document

Dies brachte mich dazu in das „bin/Debug“ Ver­zeich­nis zu schauen und siehe da, es gab keine pdb Dateien für das Pro­jekt. Um die pdb Dateien für das Pro­jekt anzu­le­gen, geht man in die Pro­jekt­ein­stel­lun­gen, dort auf „Build“ und dann auf „Advanced“.

In dem sich dar­auf öff­nen­den Dia­log stellt man die „Debug info“ auf „full“. Damit soll­ten die PDB Dateien erzeugt wer­den und das debug­gen wie­der funktionieren.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://en.wikipedia.org/wiki/Program_database
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.71%29.aspx
http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx

Ich stelle vor ein paar Tagen ein .NET Pro­jekt von .NET 2 auf .NET 4 um. An dem Pro­jekt hin­gen einige Biblio­the­ken wel­che wei­ter­hin auf .NET 2 basier­ten (und dies auch wei­ter­hin tun sol­len). Nach der Umstel­lung ergab sich nun das Pro­blem, das ich die Anwen­dung nicht mehr mit dem Debug­ger star­ten konnte.

Das Pro­blem hängt dabei damit zusam­men das das Visual Stu­dio für .NET 1 bis .NET 3.5 sowie für .NET 4 jeweils eine eigene Debu­gen­gine benutzt. Um das Pro­blem zu umge­hen schal­tete ich in den Pro­jekt­ei­gen­schaf­ten unter Debug den Ein­trag Enable the Visual Stu­dio hos­ting pro­cess aus. Danach konnte ich auch mit dem gemisch­ten Pro­jekt wie­der debuggen.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://blogs.msdn.com/b/debugger/archive/2010/04/30/can-t-hit-breakpoints-in-a-plug-in-or-can-t-debug-net-2-0-3-0-3-5-from-a-mixed-mode-exe-project-with-visual-studio-2010.aspx

Zu Debug­zwe­cken ist es manch­mal ganz prak­tisch den Inhalt einer Varia­ble (im kon­kre­ten Fall in PHP) aus­zu­ge­ben. Das würde unter PHP dann so aussehen:

echo $test;

Das Pro­blem an die­ser Methode ist, das wenn es sich um ein Array han­delt, wir nur die Ausgabe:

Array

zurück­be­kom­men. Hier hilft die print_r Funk­tion, mit wel­cher das ganze dann so aussieht:

print_r($test);

Damit bekommt man dann eine wun­der­schöne Aus­gabe des Arrays:

Array ( [0] => 1232 [1] => 1775 [2] => 8532 [3] => 3432 [4] => 1232 [5] => 384 [6] => 4357 [7] => 4334 [8] => 9888 [9] => 2442 [10] => 1212 [11] => 9989 [12] => 543 )

Wenn man unter Eclipse Android Anwen­dun­gen debug­gen möchte hat man es gar nicht so ein ein­fach. Jeder der das aus­pro­bie­ren möchte sollte fol­gende Zeile in die onCreate Methode einer Activity hin­zu­fü­gen (nach set­Con­tent­View):

int error=7/0;

Diese Zeile führt zu einer Divi­sion durch Null Excep­tion. Würde man sowas nun in C# machen und im Debug­mo­dus aus­füh­ren so wird eine Excep­tion aus­ge­löst und der Debug­ger zeigt genau die Stelle im Ori­gi­nal­code an an der der Feh­ler auf­tritt. So weiß man gleich wo der Feh­ler zu fin­den ist.

Wenn wir nun besag­tes Bei­spiel in Eclipse im Debug­mo­dus star­ten pas­siert jedoch etwas ande­res. Der Debug­ger hält irgendwo in der Datei Activi­ty­Th­read Datei an mit der Mel­dung das er den Source nicht fin­den kann. Also wel­che Mög­lich­kei­ten bleiben?

Das Debug­fens­ter ist in die­sem Moment auch nicht wirk­lich hilf­reich. Ein wenig mehr hilft der Log­Cat View (wenn er nicht vor­han­den ist, ein­fach über Win­dow -> Show View -> Other hin­zu­fü­gen) in die Excep­tion ange­zeigt wird.

Bei unse­rer Excep­tion müsste dort dann ste­hen:

Cau­sed by: java.lang.ArithmeticException: divide by Zero

Dar­un­ter steht dann der Call­stack inklu­sive Zei­len­num­mer. Damit ist die Sache dann schon ein wenig ange­neh­mer :)

Wei­tere Infor­ma­tio­nen gibt es unter:
http://www.anddev.org/a_solution_for_source_not_found_in_eclipse-t3151.html

Wenn man Android Anwen­dun­gen mit­tels Eclipse pro­gram­miert so ist man auch in Besitz eines aus­ge­wach­se­nen Debug­gers, wel­cher einem bei der Feh­ler­su­che hilf­reich zur Seite steht. Damit wir etwas zum debug­gen haben, bauen wir einen klei­nen Feh­ler in unse­rer Hello World Pro­gramm ein. Das ganze sieht dann so aus:

package net.seeseekey.hello_world;

import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;

public class hello_world extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

int result = 42/0;

TextView tv = new TextView(this);
tv.setText(result);
setContentView(tv);
}
}

Wenn wir das Pro­gramm star­ten stürzt es im Emu­la­tor ab, da eine Divi­sion durch Null nicht sehr beliebt ist. Um nun zu Debug­gen müs­sen wir einen Bre­ak­point set­zen. Die­sen Bre­ak­point set­zen wir an die Zeile int result = 42/0;. Ein Bre­ak­point wird gesetzt in dem man links von Quell­code auf der ver­ti­ka­len Leiste eine Dop­pel­klick vollführt.

Mit­tels Run -> Debug oder der F11 Taste star­ten wir das Pro­gramm im Debug­mo­dus. Beim ers­ten Start im Debug­mo­dus fragt uns Eclipse ob wir in die Debu­gan­sicht sprin­gen möch­ten was wir ableh­nen. Das Pro­gramm star­tet dann ganz nor­mal im Emu­la­tor bis der Debug­ger genau an der Stelle unter­bricht wo wir den Bre­ak­point gesetzt haben.

Nun könn­ten wir z.B. den Term 42/0 in das Expres­sion Fens­ter zie­hen (Win­dow -> Show View -> Other… -> Debug -> Expres­si­ons) und sehen dann das bei der Ope­ra­tion eine Divide by Zero herauskommt.

In dem View Debug befin­den sich außer­dem die Con­trols um durch das Pro­gramm oder in Funk­tio­nen hin­ein zu step­pen. Soviel zum Debug­ging mit­tels Eclipse und Android :)