# KDE debug: Verlangsamt USE-Flag den Desktop?

## bas89

Hallo  :Smile: 

Bisher hatte ich das debug-Flag immer deaktiviert. Da ich aber oft Abstürze feststelle¹ (KDE 4.5.4) und meine „Backtraces nutzlos“ sind, überlege ich dieses einzuschalten. Doch wieviel Festplattenplatz wird dies brauchen, und wird es die Anwendungen verlangsamen?

edit: Ich sehe gerade, dass das „debug“-Flag der falsche Ansatz ist. Viel mehr muss in den Features „splitdebug“ und in den CFLAGS „-g“ drinstehen. Die Fragen stellen sich aber weiterhin.

¹ Kontact, Amarok, KWin

----------

## Yamakuzure

Also "-g" brauchst du nicht in den CFlags. Ich habe es nicht drin, nur "splitdebug", und meine Backtraces sind immer nützlich. (Sagt DrKonqi)

Mein gesamtes System (1500+ packages) sind mit "splitdebug" erzeugt, und der Verbrauch sieht wie folgt aus:

```
# du -hsc /usr/lib/debug/*

1,9M    /usr/lib/debug/bin

212K    /usr/lib/debug/lib

496K    /usr/lib/debug/lib32

2,3M    /usr/lib/debug/lib64

996K    /usr/lib/debug/opt

2,1M    /usr/lib/debug/sbin

835M    /usr/lib/debug/usr

72K     /usr/lib/debug/var

843M    insgesamt
```

----------

## toralf

 *Yamakuzure wrote:*   

> Also "-g" brauchst du nicht in den CFlags. Ich habe es nicht drin, nur "splitdebug", und meine Backtraces sind immer nützlich.

 Interessant, ich habe nämlich grundsätzlich "-g" mit drin, wobei das wohl nur notwendig ist, wenn man auch mit dem GNU Debugger arbeiten will, oder ? :

```
tfoerste@n22 /etc/portage/env $ ls -l dev-libs/glib 

lrwxrwxrwx 1 root root 10 Feb  5  2010 dev-libs/glib -> ../default

tfoerste@n22 /etc/portage/env $ cat default 

CFLAGS="-O2 -march=native -pipe -g -ggdb"                                                

CXXFLAGS="${CFLAGS}"                                                                      

FEATURES="${FEATURES} splitdebug"

```

----------

## bas89

Nutzt Konqi nicht den gdb? Ich denke doch schon?

----------

## SinoTech

Ich glaube das USE-Flag "debug" hat nichts mit dem Debugger zu tun, dafür würde man nämlich die CFLAGS benutzen bzw. FEATURES=nostrip setzen damit die entstehenden binaries nicht gestripped werden. "debug" in den USE-Flags dürfte nur dafür sorgen das die Programme mehr Ausgaben machen (so ist es beispielsweise beim xulrunner).

Cheers,

Sino

----------

## bas89

Eine ungeklärte Frage stellt sich mir noch: Werden die Anwendungen durch die zusätzlichen debug-Informationen langsamer oder werden diese Symbole nur beim konkreten Debuggen herangezogen?

----------

## SinoTech

 *bas89 wrote:*   

> Eine ungeklärte Frage stellt sich mir noch: Werden die Anwendungen durch die zusätzlichen debug-Informationen langsamer oder werden diese Symbole nur beim konkreten Debuggen herangezogen?

 

Wenn sich der Quellcode durch setzen des Flags ändert (z.B. zusätzliche Ausgaben, checks, ...) kann sich das sehr wohl auf die Performance auswirken (das Problem hatte ich beim xulrunner).

Wenn es nur um die Debug-Informationen für den Debugger geht, und diese separat gehalten werden (FEATURES=stripdebug), sollte es keinen Unterschied machen denn die Debug-Informationen werden erst beim debuggen geladen.

Cheers,

Sino

----------

## mv

Generell ist USE="debug" Paket-spezifisch, und das genaue Verhalten hängt von Upstream ab. Meistens wird mehr geloggt, mehr Sanity-Tests durchgeführt usw.; man will das normalerweise nicht aktiviert haben, wenn man nicht gerade dabei ist, Bugs selbst auszubauen oder Bugreports zu schreiben. Was KDE speziell bei diesem Flag macht, weiß ich aber nicht.

----------

## boris64

 *mv wrote:*   

> Generell ist USE="debug" Paket-spezifisch, und das genaue Verhalten hängt von Upstream ab. Meistens wird mehr geloggt, mehr Sanity-Tests durchgeführt usw.; man will das normalerweise nicht aktiviert haben, wenn man nicht gerade dabei ist, Bugs selbst auszubauen oder Bugreports zu schreiben. Was KDE speziell bei diesem Flag macht, weiß ich aber nicht.

 

Ich würde auch raten, USE="debug" nicht global zu nutzen, da es auch zu

Fehlern führen kann. Ich für meinen Teil hatte mal 3 Monate tolle Dauerabstürze

mit akonadi und mysql, bis sich rausgestellt, dass das "debug"-Flag schuld war.

----------

