Development/Tutorials/Debugging (ko): Difference between revisions

From KDE TechBase
(+ lang bar, please read Help:Wiki Translation)
Line 1: Line 1:
{{Template:I18n/Language_Navigation_Bar|Development/Tutorials/Debugging}}
KDE 프로그램 디버깅은 별개의 단계로 이뤄집니다. 대부분의 프로그램들은 실행중 디버그문을 통해서 눈에 띄지않게 대화합니다. 이 정보를 보면 무엇이 잘못되었지 찾을 수 있는, 충분한 정보를 얻게 됩니다. 좀더 자세히 알기 위해서는 [[Development/Tutorials/Debugging/Using Error Messages|에러 메시지]]에 대한 특정 문서를 읽으세요.
KDE 프로그램 디버깅은 별개의 단계로 이뤄집니다. 대부분의 프로그램들은 실행중 디버그문을 통해서 눈에 띄지않게 대화합니다. 이 정보를 보면 무엇이 잘못되었지 찾을 수 있는, 충분한 정보를 얻게 됩니다. 좀더 자세히 알기 위해서는 [[Development/Tutorials/Debugging/Using Error Messages|에러 메시지]]에 대한 특정 문서를 읽으세요.



Revision as of 16:46, 13 January 2008


Development/Tutorials/Debugging

KDE 프로그램 디버깅은 별개의 단계로 이뤄집니다. 대부분의 프로그램들은 실행중 디버그문을 통해서 눈에 띄지않게 대화합니다. 이 정보를 보면 무엇이 잘못되었지 찾을 수 있는, 충분한 정보를 얻게 됩니다. 좀더 자세히 알기 위해서는 에러 메시지에 대한 특정 문서를 읽으세요.

Debugging KDE applications can be done on different levels. Most applications "talk" invisibly through debug statements while they are running. Looking at this information mostly gives you enough info to find out what went wrong. For further details, read the dedicated article about error messages.

별개의 단계에서 우리는 post-mortem 디버깅을 가집니다. 대부분 프로그래밍 에러로 인해, 프로그램이 죽은 에 사용됩니다. drkonqi 다이얼로그는 백트레이스를 만드는 것을 허용하고, 가능한 잘못된 곳을 찾아줍니다.

On a different level we have post-mortem debugging. This is used after an application died, probably because of a programming error. The drkonqi dialog allows you to create a backtrace, and possibly find out where it went wrong.

단지 잘못된 곳을 찾아내는 일보다 더 많은 것을 할 수 있는 gdb를 좋아하는 디버거들이 있습니다. 더 많이 찾아내기 위해 gdb의 맨페이지를 읽어야 하며, gdb보다 간단히 사용할 수 있는 'kdbg', 'ddd' 또는 'inspire'를 가능하다면 다운로드해야 합니다. 상세한 튜토리얼에 대해서는 Debugging with GDB를 읽으세요.

There are debuggers like gdb which can do a lot more than just find out where it went wrong. You should read the man page of gdb to find out more, and possibly download 'kdbg', 'ddd', or 'inspire' which make gdb a lot simpler to use. Read Debugging with GDB for a detailed tutorial.

관련 페이지들