Development/FAQs/Debugging FAQ/pl: Difference between revisions
Created page with "Aby uzyskać Dr Konqi ponownie, usuń (komendą unset) zmienną środowiskową KDE_DEBUG." |
Updating to match new version of source page |
||
(33 intermediate revisions by 2 users not shown) | |||
Line 8: | Line 8: | ||
Aby uzyskać Dr Konqi ponownie, usuń (komendą unset) zmienną środowiskową KDE_DEBUG. | Aby uzyskać Dr Konqi ponownie, usuń (komendą unset) zmienną środowiskową KDE_DEBUG. | ||
Przykład:<br /> | |||
* | *Aby uniknąć Dr Konqi: | ||
::<code>export KDE_DEBUG=1</code> | ::<code>export KDE_DEBUG=1</code> | ||
* | *Aby zobaczyć Dr Konqi: | ||
::<code>unset KDE_DEBUG</code> | ::<code>unset KDE_DEBUG</code> | ||
=== | ===Jak mogę przełączyć Dr Konqi do trybu programisty?=== | ||
W pliku $KDEHOME/share/config/drkonqirc dodaj: | |||
<syntaxhighlight lang="ini"> | <syntaxhighlight lang="ini"> | ||
[drkonqi] | [drkonqi] | ||
Line 22: | Line 22: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
=== | ===Co to jest plik core? Skąd wziąć plik core?=== | ||
Plik core to obraz pamięci w momencie zawieszenia aplikacji. Korzystając z pliku core, możesz poznać wartości zmiennych w momencie zawieszenia. | |||
Niektóre dystrybucje wyłączają generowanie plików core. Aby włączyć ponownie, użyj <code>ulimit -c unlimited</code>. | |||
Jeśli już masz plik core, możesz przebadać go przy użyciu gdb. Najbardziej przydatną komendą gdb jest <code>bt</code>, generująca zrzut, ślad po zawieszeniu aplikacji. | |||
Więcej informacji o gdb znajdziesz na [[Special:myLanguage/Development/Tutorials/Debugging/Debugging_with_GDB|tej stronie]]. | |||
=== | ===Jakich narzędzi można użyć do debuggowania mojej aplikacji?=== | ||
*kDebug() (kdDebug() | *kDebug() (kdDebug() w KDE3) zapewnia prosty, ale efektywny sposób debugowania aplikacji. | ||
*gdb, the GNU debugger, | *gdb, the GNU debugger, jest najszybszym sposobem śledzenia aplikacji krok po kroku i badania zmiennych (zalecana wersja gdb 6.x lub wyższa) | ||
*Valgrind | *Valgrind | ||
*kdbg | *kdbg jest graficznym interfejsem do gdb (z KDE GUI). Wspiera wiele typów Qt (łącznie z QString). | ||
* | *Monitor wycieków pamięci : See kdesdk/kmtrace. Plik README dostarczy informacji i wszystko wyjaśni. | ||
*qdbus | *qdbus i dbusviewer z pakietu Qt pozwala przeglądać interfejsy DBus i w łatwy sposób tworzy odwołania DBus. | ||
Sprawdź [[Special:myLanguage/Development/Tools|tę stronę]] i kdesdk, gdzie znajdziesz masę przydatnych skryptów. | |||
=== | ===Jak mogę wyświetlić QString w gdb?=== | ||
Pobierz kdesdk i w pliku ~/.gdbinit dodaj linię: | |||
{{Input|1=source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb}} | {{Input|1=source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb}} | ||
W gdb możesz wtedy użyć <code>printqstring myqstring</code>, aby zobaczyć jego zawartość. | |||
Na przykład <code>QString myqstring = QString::fromLatin1("contents");</code> może zostać prześledzony używając | |||
{{Input|1= | {{Input|1= | ||
Line 53: | Line 53: | ||
$1 = "content"}} | $1 = "content"}} | ||
Zobacz plik <tt>kde-devel-gdb</tt> z innymi makrami. | |||
=== | ===Nie mam symbolu debugując aplikację, która używa kpart. Co powinienem zrobić?=== | ||
Musisz zatrzymać się zaraz po załadowaniu symboli z biblioteki. Potem możesz normalnie debugować. | |||
Możesz utworzyć makro gdb, aby zatrzymać się zaraz po załadowanej części. W przypadku kword, na przykład, używam: | |||
{{Input|1= | {{Input|1= | ||
define startkword | define startkword | ||
Line 66: | Line 66: | ||
QObject *, char const *, bool)' cont}} | QObject *, char const *, bool)' cont}} | ||
=== | ===Jak debuggować ioslave?=== | ||
Zobacz [[Development/Tutorials/Debugging/Debugging IOSlaves|debuggowanie ioslaves]] | |||
=== | === Dlaczego mój sygnał i połączenie gniazda nie działa? === | ||
Oto kilka kroków, które można wykorzystać do rozwiązania problemu, dlaczego sygnał/gniazdo nie działa (gniazdo nie odpowiada z jakiejś przyczyny). | |||
1 | 1. Upewnij się, że connect() nie wyświetla ostrzeżenia w konsoli podczas działania. | ||
Jeśli tak, sprawdź Q_OBJECT, czy nazwy parametru nie ma w połączeniu, czy typy parametru są odpowiednie i czy gniazdo jest zdefiniowane oraz czy moc został skompilowany. | |||
1b | 1b. Lub możesz sprawdzić, co zwraca connect() mimo, że nie daje żadnego komunikatu o błędzie | ||
2 | 2. Upewnij się, że sygnał rzeczywiście jest emitowany | ||
3 | 3. Upewnij się, że odbiorca nie jest już skasowany w tym momencie | ||
4 | 4. Upewnij się, że emitter->signalsBlocked() zwraca false | ||
===Czy istnieje preferowana metoda wyświetlania danych z debuggu w stderr?=== | |||
Yes; see [[Special:myLanguage/Development/Tutorials/Debugging/Using_Error_Messages|this tutorial]]. | |||
Yes | |||
[[Category:FAQs]] | [[Category:FAQs]] | ||
[[Category:Programming]] | [[Category:Programming]] |
Latest revision as of 10:25, 11 March 2016
Ogólne
Jak mogę uniknąć Dr Konqi?
Należy ustawić zmienną środowiskową KDE_DEBUG (na 1 lub jakąkolwiek inną wartość)
Aby uzyskać Dr Konqi ponownie, usuń (komendą unset) zmienną środowiskową KDE_DEBUG.
Przykład:
- Aby uniknąć Dr Konqi:
export KDE_DEBUG=1
- Aby zobaczyć Dr Konqi:
unset KDE_DEBUG
Jak mogę przełączyć Dr Konqi do trybu programisty?
W pliku $KDEHOME/share/config/drkonqirc dodaj:
[drkonqi]
ConfigName=developer
Co to jest plik core? Skąd wziąć plik core?
Plik core to obraz pamięci w momencie zawieszenia aplikacji. Korzystając z pliku core, możesz poznać wartości zmiennych w momencie zawieszenia.
Niektóre dystrybucje wyłączają generowanie plików core. Aby włączyć ponownie, użyj ulimit -c unlimited
.
Jeśli już masz plik core, możesz przebadać go przy użyciu gdb. Najbardziej przydatną komendą gdb jest bt
, generująca zrzut, ślad po zawieszeniu aplikacji.
Więcej informacji o gdb znajdziesz na tej stronie.
Jakich narzędzi można użyć do debuggowania mojej aplikacji?
- kDebug() (kdDebug() w KDE3) zapewnia prosty, ale efektywny sposób debugowania aplikacji.
- gdb, the GNU debugger, jest najszybszym sposobem śledzenia aplikacji krok po kroku i badania zmiennych (zalecana wersja gdb 6.x lub wyższa)
- Valgrind
- kdbg jest graficznym interfejsem do gdb (z KDE GUI). Wspiera wiele typów Qt (łącznie z QString).
- Monitor wycieków pamięci : See kdesdk/kmtrace. Plik README dostarczy informacji i wszystko wyjaśni.
- qdbus i dbusviewer z pakietu Qt pozwala przeglądać interfejsy DBus i w łatwy sposób tworzy odwołania DBus.
Sprawdź tę stronę i kdesdk, gdzie znajdziesz masę przydatnych skryptów.
Jak mogę wyświetlić QString w gdb?
Pobierz kdesdk i w pliku ~/.gdbinit dodaj linię:
source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb
W gdb możesz wtedy użyć printqstring myqstring
, aby zobaczyć jego zawartość.
Na przykład QString myqstring = QString::fromLatin1("contents");
może zostać prześledzony używając
(gdb) printqstring myqstring $1 = "content"
Zobacz plik kde-devel-gdb z innymi makrami.
Nie mam symbolu debugując aplikację, która używa kpart. Co powinienem zrobić?
Musisz zatrzymać się zaraz po załadowaniu symboli z biblioteki. Potem możesz normalnie debugować. Możesz utworzyć makro gdb, aby zatrzymać się zaraz po załadowanej części. W przypadku kword, na przykład, używam:
define startkword break main run break 'KoDocument::KoDocument(int, QWidget *, char const *, QObject *, char const *, bool)' cont
Jak debuggować ioslave?
Zobacz debuggowanie ioslaves
Dlaczego mój sygnał i połączenie gniazda nie działa?
Oto kilka kroków, które można wykorzystać do rozwiązania problemu, dlaczego sygnał/gniazdo nie działa (gniazdo nie odpowiada z jakiejś przyczyny).
1. Upewnij się, że connect() nie wyświetla ostrzeżenia w konsoli podczas działania.
Jeśli tak, sprawdź Q_OBJECT, czy nazwy parametru nie ma w połączeniu, czy typy parametru są odpowiednie i czy gniazdo jest zdefiniowane oraz czy moc został skompilowany.
1b. Lub możesz sprawdzić, co zwraca connect() mimo, że nie daje żadnego komunikatu o błędzie 2. Upewnij się, że sygnał rzeczywiście jest emitowany 3. Upewnij się, że odbiorca nie jest już skasowany w tym momencie 4. Upewnij się, że emitter->signalsBlocked() zwraca false
Czy istnieje preferowana metoda wyświetlania danych z debuggu w stderr?
Yes; see this tutorial.