Mercurial > hg > xemacs-beta

comparison man/xemacs-faq.texi @ 1183:c1553814932e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
[xemacs-hg @ 2003-01-03 12:12:30 by stephent] various docs <873coa5unb.fsf@tleepslib.sk.tsukuba.ac.jp> <87r8bu4emz.fsf@tleepslib.sk.tsukuba.ac.jp>
author stephent
date Fri, 03 Jan 2003 12:12:40 +0000
parents 820f727b1801
children 473e76fb6d95
comparison
equal deleted inserted replaced
1182:7d696106ffe9 1183:c1553814932e
5 @setchapternewpage off 5 @setchapternewpage off
6 @c %**end of header 6 @c %**end of header
7 @finalout 7 @finalout
8 @titlepage 8 @titlepage
9 @title XEmacs FAQ 9 @title XEmacs FAQ
10 @subtitle Frequently asked questions about XEmacs @* Last Modified: $Date: 2002/12/04 14:06:04 $ 10 @subtitle Frequently asked questions about XEmacs @* Last Modified: $Date: 2003/01/03 12:12:30 $
11 @sp 1 11 @sp 1
12 @author Tony Rossini <rossini@@biostat.washington.edu> 12 @author Tony Rossini <rossini@@biostat.washington.edu>
13 @author Ben Wing <ben@@xemacs.org> 13 @author Ben Wing <ben@@xemacs.org>
14 @author Chuck Thompson <cthomp@@xemacs.org> 14 @author Chuck Thompson <cthomp@@xemacs.org>
15 @author Steve Baur <steve@@xemacs.org> 15 @author Steve Baur <steve@@xemacs.org>
1498 1498
1499 There have been a variety of reports of crashes due to compilers with 1499 There have been a variety of reports of crashes due to compilers with
1500 buggy optimizers. Please see the @file{PROBLEMS} file that comes with 1500 buggy optimizers. Please see the @file{PROBLEMS} file that comes with
1501 XEmacs to read what it says about your platform. 1501 XEmacs to read what it says about your platform.
1502 1502
1503 If you compiled XEmacs using @samp{--use-union-type} (or the option
1504 @samp{USE_UNION_TYPE} in @file{config.inc} under Windows), recompile
1505 again without this. This has been known to trigger compiler errors in a
1506 number of cases.
1507
1503 @node Q2.0.7, Q2.0.8, Q2.0.6, Installation 1508 @node Q2.0.7, Q2.0.8, Q2.0.6, Installation
1504 @unnumberedsubsec Q2.0.7: Libraries in non-standard locations 1509 @unnumberedsubsec Q2.0.7: Libraries in non-standard locations
1505 1510
1506 I have x-faces, jpeg, xpm etc. all in different places. I've tried 1511 I have x-faces, jpeg, xpm etc. all in different places. I've tried
1507 space-separated, comma-separated, several --site-libraries, all to no 1512 space-separated, comma-separated, several --site-libraries, all to no
1800 1805
1801 Now, XEmacs is not perfect, and there may occasionally be times, or 1806 Now, XEmacs is not perfect, and there may occasionally be times, or
1802 particular sequences of actions, that cause it to crash. If you can 1807 particular sequences of actions, that cause it to crash. If you can
1803 come up with a reproducible way of doing this (or even if you have a 1808 come up with a reproducible way of doing this (or even if you have a
1804 pretty good memory of exactly what you were doing at the time), the 1809 pretty good memory of exactly what you were doing at the time), the
1805 maintainers would be very interested in knowing about it. Post a 1810 maintainers would be very interested in knowing about it. The best way
1806 message to comp.emacs.xemacs or send mail to @email{crashes@@xemacs.org}. 1811 to report a bug is using @kbd{M-x report-emacs-bug} (or by selecting
1807 Please note that the @samp{crashes} address is exclusively for crash 1812 @samp{Send Bug Report...} from the Help menu). If that won't work
1813 (e.g. you can't get XEmacs working at all), send ordinary mail to
1814 @email{crashes@@xemacs.org}. @emph{MAKE SURE} to include the output from
1815 the crash, especially including the Lisp backtrace, as well as the
1816 XEmacs configuration from @kbd{M-x describe-installation} (or
1817 equivalently, the file @file{Installation} in the top of the build
1818 tree). Please note that the @samp{crashes} address is exclusively for
1819 crash reports. The best way to report bugs in general is through the
1820 @kbd{M-x report-emacs-bug} interface just mentioned, or if necessary by
1821 emailing @email{xemacs-beta@@xemacs.org}. Note that the developers do
1822 @emph{not} usually follow @samp{comp.emacs.xemacs} on a regular basis;
1823 thus, this is better for general questions about XEmacs than bug
1808 reports. 1824 reports.
1809 1825
1810 If at all possible, include a stack backtrace of the core dump that was 1826 If at all possible, include a C stack backtrace of the core dump that
1811 produced. This shows where exactly things went wrong, and makes it much 1827 was produced. This shows where exactly things went wrong, and makes it
1812 easier to diagnose problems. To do this, you need to locate the core 1828 much easier to diagnose problems. To do this under Unix, you need to
1813 file (it's called @file{core}, and is usually sitting in the directory 1829 locate the core file (it's called @file{core}, and is usually sitting in
1814 that you started XEmacs from, or your home directory if that other 1830 the directory that you started XEmacs from, or your home directory if
1815 directory was not writable). Then, go to that directory and execute a 1831 that other directory was not writable). Then, go to that directory and
1816 command like: 1832 execute a command like:
1817 1833
1818 @example 1834 @example
1819 gdb `which xemacs` core 1835 gdb `which xemacs` core
1820 @end example 1836 @end example
1821 1837
1827 It's possible that a core file didn't get produced, in which case you're 1843 It's possible that a core file didn't get produced, in which case you're
1828 out of luck. Go complain to your system administrator and tell him not 1844 out of luck. Go complain to your system administrator and tell him not
1829 to disable core files by default. Also see @ref{Q2.1.15}, for tips and 1845 to disable core files by default. Also see @ref{Q2.1.15}, for tips and
1830 techniques for dealing with a debugger. 1846 techniques for dealing with a debugger.
1831 1847
1848 If you're under Microsoft Windows, you're out of luck unless you happen
1849 to have a debugging aid installed on your system, for example Visual
1850 C++. In this case, the crash will result in a message giving you the
1851 option to enter a debugger (for example, by pressing @samp{Cancel}). Do
1852 this and locate the stack-trace window. (If your XEmacs was built
1853 without debugging information, the stack trace may not be very useful.)
1854
1832 When making a problem report make sure that: 1855 When making a problem report make sure that:
1833 1856
1834 @enumerate 1857 @enumerate
1835 @item 1858 @item
1836 Report @strong{all} of the information output by XEmacs during the 1859 Report @strong{all} of the information output by XEmacs during the
1844 1867
1845 @item 1868 @item
1846 What build options you are using. 1869 What build options you are using.
1847 1870
1848 @item 1871 @item
1849 If the problem is related to graphics, we will also need to know what 1872 If the problem is related to graphics and you are running Unix, we will
1850 version of the X Window System you are running, and what window manager 1873 also need to know what version of the X Window System you are running,
1851 you are using. 1874 and what window manager you are using.
1852 1875
1853 @item 1876 @item
1854 If the problem happened on a tty, please include the terminal type. 1877 If the problem happened on a TTY, please include the terminal type.
1855 @end enumerate 1878 @end enumerate
1856 1879
1857 Much of the information above is automatically generated by @kbd{M-x 1880 Much of the information above is automatically generated by @kbd{M-x
1858 report-emacs-bug}. Even more, and often useful, information can be 1881 report-emacs-bug}. Even more, and often useful, information can be
1859 generated by redirecting the output of @code{make} and @code{make check} 1882 generated by redirecting the output of @code{make} and @code{make check}
2235 i.e. references to Lisp objects. Printing them out with the debugger 2258 i.e. references to Lisp objects. Printing them out with the debugger
2236 probably won't be too useful---you'll likely just see a number. To 2259 probably won't be too useful---you'll likely just see a number. To
2237 decode them, do this: 2260 decode them, do this:
2238 2261
2239 @example 2262 @example
2240 call debug_print (OBJECT) 2263 call dp (OBJECT)
2241 @end example 2264 @end example
2242 2265
2243 where @var{OBJECT} is whatever you want to decode (it can be a variable, 2266 where @var{OBJECT} is whatever you want to decode (it can be a variable,
2244 a function call, etc.). This will print out a readable representation 2267 a function call, etc.). This will print out a readable representation
2245 on the TTY from which the xemacs process was invoked. 2268 on the TTY from which the xemacs process was invoked.
2247 @item 2270 @item
2248 If you want to get a Lisp backtrace showing the Lisp call 2271 If you want to get a Lisp backtrace showing the Lisp call
2249 stack, do this: 2272 stack, do this:
2250 2273
2251 @example 2274 @example
2252 call debug_backtrace () 2275 call db ()
2253 @end example 2276 @end example
2254 2277
2255 @item 2278 @item
2256 Using @code{debug_print} and @code{debug_backtrace} has two 2279 Using @code{dp} and @code{db} has two disadvantages - it can only be
2257 disadvantages - it can only be used with a running xemacs process, and 2280 used with a running xemacs process, and it cannot display the internal C
2258 it cannot display the internal C structure of a Lisp Object. Even if 2281 structure of a Lisp Object. Even if all you've got is a core dump, all
2259 all you've got is a core dump, all is not lost. 2282 is not lost.
2260 2283
2261 If you're using GDB, there are some macros in the file 2284 If you're using GDB, there are some macros in the file
2262 @file{src/.gdbinit} in the XEmacs source distribution that should make 2285 @file{src/.gdbinit} in the XEmacs source distribution that should make
2263 it easier for you to decode Lisp objects. This file is automatically 2286 it easier for you to decode Lisp objects. This file is automatically
2264 read by gdb if gdb is run in the directory where xemacs was built, and 2287 read by gdb if gdb is run in the directory where xemacs was built, and
2317 Linux), stack backtraces of core dumps will have the frame where the 2340 Linux), stack backtraces of core dumps will have the frame where the
2318 fatal signal occurred mangled; if you can obtain a stack trace while 2341 fatal signal occurred mangled; if you can obtain a stack trace while
2319 running the XEmacs process under a debugger, the stack trace should be 2342 running the XEmacs process under a debugger, the stack trace should be
2320 clean. 2343 clean.
2321 2344
2322 @email{1CMC3466@@ibm.mtsac.edu, Curtiss} suggests upgrading to ld.so version 1.8 2345 @email{1CMC3466@@ibm.mtsac.edu, Curtiss} suggests upgrading to ld.so
2323 if dynamic linking and debugging is a problem on Linux. 2346 version 1.8 if dynamic linking and debugging is a problem on Linux.
2324 2347
2325 @item 2348 @item
2326 If you're using a debugger to get a C stack backtrace and you're 2349 If you're using a debugger to get a C stack backtrace and you're
2327 getting a completely mangled and bogus stack trace, it's probably due to 2350 getting a completely mangled and bogus stack trace, it's probably due to
2328 one of the following: 2351 one of the following:
2342 @item 2365 @item
2343 If your stack trace has exactly one frame in it, with address 0x0, this 2366 If your stack trace has exactly one frame in it, with address 0x0, this
2344 could simply mean that XEmacs attempted to execute code at that address, 2367 could simply mean that XEmacs attempted to execute code at that address,
2345 e.g. through jumping to a null function pointer. Unfortunately, under 2368 e.g. through jumping to a null function pointer. Unfortunately, under
2346 those circumstances, GDB under Linux doesn't know how to get a stack 2369 those circumstances, GDB under Linux doesn't know how to get a stack
2347 trace. (Yes, this is the third Linux-related problem I've mentioned. I 2370 trace. (Yes, this is the fourth Linux-related problem I've mentioned. I
2348 have no idea why GDB under Linux is so bogus. Complain to the GDB 2371 have no idea why GDB under Linux is so bogus. Complain to the GDB
2349 authors, or to comp.os.linux.development.system). Again, you'll have to 2372 authors, or to comp.os.linux.development.system.) Again, you'll have to
2350 use the narrowing-down process described above. 2373 use the narrowing-down process described above.
2351 2374
2352 @item 2375 @item
2353 You will get a Lisp backtrace output when XEmacs crashes, so you'll have 2376 You will get a Lisp backtrace output when XEmacs crashes, so you'll have
2354 something useful. 2377 something useful.
2362 2385
2363 @item 2386 @item
2364 In versions of XEmacs before 21.2.27, @file{src/.gdbinit} was named 2387 In versions of XEmacs before 21.2.27, @file{src/.gdbinit} was named
2365 @file{src/gdbinit}. This had the disadvantage of not being sourced 2388 @file{src/gdbinit}. This had the disadvantage of not being sourced
2366 automatically by gdb, so you had to set that up yourself. 2389 automatically by gdb, so you had to set that up yourself.
2390
2391 @item
2392 If you are running Microsoft Windows, the the file @file{nt/README} for
2393 further information about debugging XEmacs.
2367 2394
2368 @end itemize 2395 @end itemize
2369 2396
2370 @node Q2.1.16, Q2.1.17, Q2.1.15, Installation 2397 @node Q2.1.16, Q2.1.17, Q2.1.15, Installation
2371 @unnumberedsubsec Q2.1.16: XEmacs crashes in @code{strcat} on HP/UX 10 2398 @unnumberedsubsec Q2.1.16: XEmacs crashes in @code{strcat} on HP/UX 10