* How to debug out of memory situation?
@ 2003-05-27 15:06 Kai Großjohann
2003-05-28 23:57 ` Richard Stallman
0 siblings, 1 reply; 4+ messages in thread
From: Kai Großjohann @ 2003-05-27 15:06 UTC (permalink / raw)
When using Gnus from CVS (I mean the CVS at gnus.org) together with
Emacs from CVS, and I tell the Agent to fetch articles, then I often
get an out of memory error.
At one point, I was actually thrown into the (Lisp-level) debugger,
and at that point I did M-x apropos-value RET ^.\{10000\} RET (also
the same without backslashes), but that didn't find anything.
Is there a way for me to figure out where the memory is gone, so that
Emacs has no more memory?
Hm. Maybe I should have said M-x apropos-value RET \`\(.\| C-q C-j
\)\{10000\} RET.
Most of the time, Emacs doesn't go into the debugger. Instead, it
beeps endlessly. Sometimes, it prints a warning about memory full
and advises me to save buffers and kill Emacs. Sometimes it gives me
a memory-full warning and asks me whether to continue. I think both
answers (yes, and no) result in endless beeps...
--
This line is not blank.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: How to debug out of memory situation?
2003-05-27 15:06 How to debug out of memory situation? Kai Großjohann
@ 2003-05-28 23:57 ` Richard Stallman
2003-06-09 17:23 ` Kai Großjohann
0 siblings, 1 reply; 4+ messages in thread
From: Richard Stallman @ 2003-05-28 23:57 UTC (permalink / raw)
Cc: emacs-devel
If you put a breakpoint in memory_full, you will be able to make a
backtrace. If Emacs is continuing to use memory for a certain purpose
and ran out while trying to do more of that, you should see within a
few cases what the pattern is.
It might be useful to add more history records of why memory was
allocated, for the last 20 times (say). It is not easy to see how to
record the history. A useful history record might really want to be a
backtrace of some sort. Perhaps a list of the innermost 10 Lisp
functions (which can be found by scanning `backlist') would be useful.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: How to debug out of memory situation?
2003-05-28 23:57 ` Richard Stallman
@ 2003-06-09 17:23 ` Kai Großjohann
2003-06-15 15:59 ` Richard Stallman
0 siblings, 1 reply; 4+ messages in thread
From: Kai Großjohann @ 2003-06-09 17:23 UTC (permalink / raw)
Richard Stallman <rms@gnu.org> writes:
> If you put a breakpoint in memory_full, you will be able to make a
> backtrace. If Emacs is continuing to use memory for a certain purpose
> and ran out while trying to do more of that, you should see within a
> few cases what the pattern is.
I tried this a couple of times but couldn't really find anything.
Now I tried it again and this time, I at least got some backtraces.
They were not so interesting, I'm afraid :-/
Here is the first time it happened: (Search for CCC to find the end
of the gdb output.)
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) bt
#0 memory_full () at alloc.c:464
#1 0x0811b3cd in lisp_malloc (nbytes=48, type=MEM_TYPE_VECTOR) at alloc.c:615
#2 0x0811c590 in allocate_vectorlike (len=10, type=MEM_TYPE_VECTOR)
at alloc.c:2253
#3 0x0811c5e5 in allocate_vector (nslots=10) at alloc.c:2276
#4 0x0811c73e in Fmake_vector (length=10, init=405487172) at alloc.c:2372
#5 0x0811c88e in Fvector (nargs=10, args=0xbfffd8c8) at alloc.c:2437
#6 0x08131016 in Ffuncall (nargs=11, args=0xbfffd8c4) at eval.c:2705
#7 0x0815842c in Fbyte_code (bytestr=942873532, vector=1221889640, maxdepth=16)
at bytecode.c:710
#8 0x08130724 in Feval (form=1489062228) at eval.c:2084
#9 0x0812f57d in Fcondition_case (args=1525038380) at eval.c:1280
#10 0x081588ca in Fbyte_code (bytestr=945883100, vector=1221890072, maxdepth=8)
at bytecode.c:891
#11 0x081315d1 in funcall_lambda (fun=1221890304, nargs=4, arg_vector=0xbfffdc48)
at eval.c:2911
#12 0x08131191 in Ffuncall (nargs=5, args=0xbfffdc44) at eval.c:2781
#13 0x0815842c in Fbyte_code (bytestr=955457068, vector=1223899728, maxdepth=19)
at bytecode.c:710
#14 0x081315d1 in funcall_lambda (fun=1223900240, nargs=2, arg_vector=0xbfffdd34)
at eval.c:2911
#15 0x081312d4 in apply_lambda (fun=1223900240, args=1492329948, eval_flag=1)
at eval.c:2833
#16 0x0813088e in Feval (form=1492329940) at eval.c:2136
#17 0x0812f57d in Fcondition_case (args=1538322764) at eval.c:1280
#18 0x081588ca in Fbyte_code (bytestr=955456908, vector=1223897312, maxdepth=5)
at bytecode.c:891
#19 0x081315d1 in funcall_lambda (fun=1223897552, nargs=0, arg_vector=0xbfffe0a8)
at eval.c:2911
#20 0x08131191 in Ffuncall (nargs=1, args=0xbfffe0a4) at eval.c:2781
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) xbacktrace
"vector"
"byte-code"
"gnus-get-newsgroup-headers-xover"
"gnus-agent-fetch-group-1"
"gnus-agent-fetch-session"
"call-interactively"
CCC
Okay, so the function is gnus-get-newsgroup-headers-xover. I then
continue.
(gdb) cont
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) xbacktrace
"expand-file-name"
"apply"
"jka-compr-run-real-handler"
"jka-compr-handler"
"debug"
"byte-code"
"gnus-get-newsgroup-headers-xover"
"gnus-agent-fetch-group-1"
"gnus-agent-fetch-session"
"call-interactively"
CCC
Still gnus-get-newsgroup-headers-xover, it seems. But from now on,
it gets less interesting really fast. (No more text until end of
this message -- just gdb output.)
I really feel I'm fishing in muddy waters and I have no idea what I
can do. There are probably ways to find out more, but I don't know
them.
Help?
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) xbacktrace
"format"
"byte-code"
"gnus-agent-fetch-session"
"call-interactively"
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) xbacktrace
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) xbacktrace
(gdb) xbacktrace
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) xbacktrace
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) xbacktrace
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) bt
#0 memory_full () at alloc.c:464
#1 0x0811b3cd in lisp_malloc (nbytes=1012, type=MEM_TYPE_STRING) at alloc.c:615
#2 0x0811b88b in allocate_string () at alloc.c:1321
#3 0x0811c0dd in make_uninit_multibyte_string (nchars=9, nbytes=9)
at alloc.c:1895
#4 0x0811c0ab in make_uninit_string (length=9) at alloc.c:1876
#5 0x0811bf50 in make_unibyte_string (contents=0x8184da0 "emergency", length=9)
at alloc.c:1790
#6 0x0811bf22 in make_string (contents=0x8184da0 "emergency", nbytes=9)
at alloc.c:1775
#7 0x081461bf in intern (str=0x8184da0 "emergency") at lread.c:3092
#8 0x0811b0b3 in display_malloc_warning () at alloc.c:441
#9 0x080d9fb5 in command_loop_1 () at keyboard.c:1443
#10 0x0812f66d in internal_condition_case (bfun=0x80d9e00 <command_loop_1>,
handlers=405583908, hfun=0x80d9a04 <cmd_error>) at eval.c:1333
#11 0x080d9cc8 in command_loop_2 () at keyboard.c:1292
#12 0x0812f1e5 in internal_catch (tag=405545156,
func=0x80d9ca4 <command_loop_2>, arg=405487172) at eval.c:1094
#13 0x080d9c73 in command_loop () at keyboard.c:1271
#14 0x080d97c8 in recursive_edit_1 () at keyboard.c:987
#15 0x080d98f0 in Frecursive_edit () at keyboard.c:1043
#16 0x080d8773 in main (argc=3, argv=0xbfffe824) at emacs.c:1666
(gdb) xbacktrace
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) xbacktrace
(gdb) bt
#0 memory_full () at alloc.c:464
#1 0x0811b3cd in lisp_malloc (nbytes=1012, type=MEM_TYPE_STRING) at alloc.c:615
#2 0x0811b88b in allocate_string () at alloc.c:1321
#3 0x0811c0dd in make_uninit_multibyte_string (nchars=9, nbytes=9)
at alloc.c:1895
#4 0x0811c0ab in make_uninit_string (length=9) at alloc.c:1876
#5 0x0811bf50 in make_unibyte_string (contents=0x8184da0 "emergency", length=9)
at alloc.c:1790
#6 0x0811bf22 in make_string (contents=0x8184da0 "emergency", nbytes=9)
at alloc.c:1775
#7 0x081461bf in intern (str=0x8184da0 "emergency") at lread.c:3092
#8 0x0811b0b3 in display_malloc_warning () at alloc.c:441
#9 0x080d9fb5 in command_loop_1 () at keyboard.c:1443
#10 0x0812f66d in internal_condition_case (bfun=0x80d9e00 <command_loop_1>,
handlers=405583908, hfun=0x80d9a04 <cmd_error>) at eval.c:1333
#11 0x080d9cc8 in command_loop_2 () at keyboard.c:1292
#12 0x0812f1e5 in internal_catch (tag=405545156,
func=0x80d9ca4 <command_loop_2>, arg=405487172) at eval.c:1094
#13 0x080d9c73 in command_loop () at keyboard.c:1271
#14 0x080d97c8 in recursive_edit_1 () at keyboard.c:987
#15 0x080d98f0 in Frecursive_edit () at keyboard.c:1043
#16 0x080d8773 in main (argc=3, argv=0xbfffe824) at emacs.c:1666
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) bt
#0 memory_full () at alloc.c:464
#1 0x0811b3cd in lisp_malloc (nbytes=1012, type=MEM_TYPE_STRING) at alloc.c:615
#2 0x0811b88b in allocate_string () at alloc.c:1321
#3 0x0811c0dd in make_uninit_multibyte_string (nchars=9, nbytes=9)
at alloc.c:1895
#4 0x0811c0ab in make_uninit_string (length=9) at alloc.c:1876
#5 0x0811bf50 in make_unibyte_string (contents=0x8184da0 "emergency", length=9)
at alloc.c:1790
#6 0x0811bf22 in make_string (contents=0x8184da0 "emergency", nbytes=9)
at alloc.c:1775
#7 0x081461bf in intern (str=0x8184da0 "emergency") at lread.c:3092
#8 0x0811b0b3 in display_malloc_warning () at alloc.c:441
#9 0x080d9fb5 in command_loop_1 () at keyboard.c:1443
#10 0x0812f66d in internal_condition_case (bfun=0x80d9e00 <command_loop_1>,
handlers=405583908, hfun=0x80d9a04 <cmd_error>) at eval.c:1333
#11 0x080d9cc8 in command_loop_2 () at keyboard.c:1292
#12 0x0812f1e5 in internal_catch (tag=405545156,
func=0x80d9ca4 <command_loop_2>, arg=405487172) at eval.c:1094
#13 0x080d9c73 in command_loop () at keyboard.c:1271
#14 0x080d97c8 in recursive_edit_1 () at keyboard.c:987
#15 0x080d98f0 in Frecursive_edit () at keyboard.c:1043
#16 0x080d8773 in main (argc=3, argv=0xbfffe824) at emacs.c:1666
(gdb) where
#0 memory_full () at alloc.c:464
#1 0x0811b3cd in lisp_malloc (nbytes=1012, type=MEM_TYPE_STRING) at alloc.c:615
#2 0x0811b88b in allocate_string () at alloc.c:1321
#3 0x0811c0dd in make_uninit_multibyte_string (nchars=9, nbytes=9)
at alloc.c:1895
#4 0x0811c0ab in make_uninit_string (length=9) at alloc.c:1876
#5 0x0811bf50 in make_unibyte_string (contents=0x8184da0 "emergency", length=9)
at alloc.c:1790
#6 0x0811bf22 in make_string (contents=0x8184da0 "emergency", nbytes=9)
at alloc.c:1775
#7 0x081461bf in intern (str=0x8184da0 "emergency") at lread.c:3092
#8 0x0811b0b3 in display_malloc_warning () at alloc.c:441
#9 0x080d9fb5 in command_loop_1 () at keyboard.c:1443
#10 0x0812f66d in internal_condition_case (bfun=0x80d9e00 <command_loop_1>,
handlers=405583908, hfun=0x80d9a04 <cmd_error>) at eval.c:1333
#11 0x080d9cc8 in command_loop_2 () at keyboard.c:1292
#12 0x0812f1e5 in internal_catch (tag=405545156,
func=0x80d9ca4 <command_loop_2>, arg=405487172) at eval.c:1094
#13 0x080d9c73 in command_loop () at keyboard.c:1271
#14 0x080d97c8 in recursive_edit_1 () at keyboard.c:987
#15 0x080d98f0 in Frecursive_edit () at keyboard.c:1043
#16 0x080d8773 in main (argc=3, argv=0xbfffe824) at emacs.c:1666
(gdb) wh
wh whatis where while while-stepping
(gdb) bt
#0 memory_full () at alloc.c:464
#1 0x0811b3cd in lisp_malloc (nbytes=1012, type=MEM_TYPE_STRING) at alloc.c:615
#2 0x0811b88b in allocate_string () at alloc.c:1321
#3 0x0811c0dd in make_uninit_multibyte_string (nchars=9, nbytes=9)
at alloc.c:1895
#4 0x0811c0ab in make_uninit_string (length=9) at alloc.c:1876
#5 0x0811bf50 in make_unibyte_string (contents=0x8184da0 "emergency", length=9)
at alloc.c:1790
#6 0x0811bf22 in make_string (contents=0x8184da0 "emergency", nbytes=9)
at alloc.c:1775
#7 0x081461bf in intern (str=0x8184da0 "emergency") at lread.c:3092
#8 0x0811b0b3 in display_malloc_warning () at alloc.c:441
#9 0x080d9fb5 in command_loop_1 () at keyboard.c:1443
#10 0x0812f66d in internal_condition_case (bfun=0x80d9e00 <command_loop_1>,
handlers=405583908, hfun=0x80d9a04 <cmd_error>) at eval.c:1333
#11 0x080d9cc8 in command_loop_2 () at keyboard.c:1292
#12 0x0812f1e5 in internal_catch (tag=405545156,
func=0x80d9ca4 <command_loop_2>, arg=405487172) at eval.c:1094
#13 0x080d9c73 in command_loop () at keyboard.c:1271
#14 0x080d97c8 in recursive_edit_1 () at keyboard.c:987
#15 0x080d98f0 in Frecursive_edit () at keyboard.c:1043
#16 0x080d8773 in main (argc=3, argv=0xbfffe824) at emacs.c:1666
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) bt
#0 memory_full () at alloc.c:464
#1 0x0811b3cd in lisp_malloc (nbytes=1012, type=MEM_TYPE_STRING) at alloc.c:615
#2 0x0811b88b in allocate_string () at alloc.c:1321
#3 0x0811c0dd in make_uninit_multibyte_string (nchars=9, nbytes=9)
at alloc.c:1895
#4 0x0811c0ab in make_uninit_string (length=9) at alloc.c:1876
#5 0x0811bf50 in make_unibyte_string (contents=0x8184da0 "emergency", length=9)
at alloc.c:1790
#6 0x0811bf22 in make_string (contents=0x8184da0 "emergency", nbytes=9)
at alloc.c:1775
#7 0x081461bf in intern (str=0x8184da0 "emergency") at lread.c:3092
#8 0x0811b0b3 in display_malloc_warning () at alloc.c:441
#9 0x080d9fb5 in command_loop_1 () at keyboard.c:1443
#10 0x0812f66d in internal_condition_case (bfun=0x80d9e00 <command_loop_1>,
handlers=405583908, hfun=0x80d9a04 <cmd_error>) at eval.c:1333
#11 0x080d9cc8 in command_loop_2 () at keyboard.c:1292
#12 0x0812f1e5 in internal_catch (tag=405545156,
func=0x80d9ca4 <command_loop_2>, arg=405487172) at eval.c:1094
#13 0x080d9c73 in command_loop () at keyboard.c:1271
#14 0x080d97c8 in recursive_edit_1 () at keyboard.c:987
#15 0x080d98f0 in Frecursive_edit () at keyboard.c:1043
#16 0x080d8773 in main (argc=3, argv=0xbfffe824) at emacs.c:1666
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) bt
#0 memory_full () at alloc.c:464
#1 0x0811b3cd in lisp_malloc (nbytes=1012, type=MEM_TYPE_STRING) at alloc.c:615
#2 0x0811b88b in allocate_string () at alloc.c:1321
#3 0x0811c0dd in make_uninit_multibyte_string (nchars=9, nbytes=9)
at alloc.c:1895
#4 0x0811c0ab in make_uninit_string (length=9) at alloc.c:1876
#5 0x0811bf50 in make_unibyte_string (contents=0x8184da0 "emergency", length=9)
at alloc.c:1790
#6 0x0811bf22 in make_string (contents=0x8184da0 "emergency", nbytes=9)
at alloc.c:1775
#7 0x081461bf in intern (str=0x8184da0 "emergency") at lread.c:3092
#8 0x0811b0b3 in display_malloc_warning () at alloc.c:441
#9 0x080d9fb5 in command_loop_1 () at keyboard.c:1443
#10 0x0812f66d in internal_condition_case (bfun=0x80d9e00 <command_loop_1>,
handlers=405583908, hfun=0x80d9a04 <cmd_error>) at eval.c:1333
#11 0x080d9cc8 in command_loop_2 () at keyboard.c:1292
#12 0x0812f1e5 in internal_catch (tag=405545156,
func=0x80d9ca4 <command_loop_2>, arg=405487172) at eval.c:1094
#13 0x080d9c73 in command_loop () at keyboard.c:1271
#14 0x080d97c8 in recursive_edit_1 () at keyboard.c:987
#15 0x080d98f0 in Frecursive_edit () at keyboard.c:1043
#16 0x080d8773 in main (argc=3, argv=0xbfffe824) at emacs.c:1666
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) c
Continuing.
Breakpoint 3, memory_full () at alloc.c:464
464 bytes_used_when_full = BYTES_USED;
(gdb) bt
#0 memory_full () at alloc.c:464
#1 0x0811b3cd in lisp_malloc (nbytes=1012, type=MEM_TYPE_STRING) at alloc.c:615
#2 0x0811b88b in allocate_string () at alloc.c:1321
#3 0x0811c0dd in make_uninit_multibyte_string (nchars=9, nbytes=9)
at alloc.c:1895
#4 0x0811c0ab in make_uninit_string (length=9) at alloc.c:1876
#5 0x0811bf50 in make_unibyte_string (contents=0x8184da0 "emergency", length=9)
at alloc.c:1790
#6 0x0811bf22 in make_string (contents=0x8184da0 "emergency", nbytes=9)
at alloc.c:1775
#7 0x081461bf in intern (str=0x8184da0 "emergency") at lread.c:3092
#8 0x0811b0b3 in display_malloc_warning () at alloc.c:441
#9 0x080d9fb5 in command_loop_1 () at keyboard.c:1443
#10 0x0812f66d in internal_condition_case (bfun=0x80d9e00 <command_loop_1>,
handlers=405583908, hfun=0x80d9a04 <cmd_error>) at eval.c:1333
#11 0x080d9cc8 in command_loop_2 () at keyboard.c:1292
#12 0x0812f1e5 in internal_catch (tag=405545156,
func=0x80d9ca4 <command_loop_2>, arg=405487172) at eval.c:1094
#13 0x080d9c73 in command_loop () at keyboard.c:1271
#14 0x080d97c8 in recursive_edit_1 () at keyboard.c:987
#15 0x080d98f0 in Frecursive_edit () at keyboard.c:1043
#16 0x080d8773 in main (argc=3, argv=0xbfffe824) at emacs.c:1666
(gdb) xbacktrace
(gdb) xbacktrace
--
This line is not blank.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: How to debug out of memory situation?
2003-06-09 17:23 ` Kai Großjohann
@ 2003-06-15 15:59 ` Richard Stallman
0 siblings, 0 replies; 4+ messages in thread
From: Richard Stallman @ 2003-06-15 15:59 UTC (permalink / raw)
Cc: emacs-devel
Once you get a memory-full error in a certain session, you probably
won't learn anything more from successive memory-full errors in the
same session. They are all secondary consequences of the first.
However, if you look at the first memory-full error in each session,
for a number of sessions, they may show a pattern that indicates
something about what code is causing the problem.
The first instance, as you reported it, is this:
"gnus-get-newsgroup-headers-xover"
"gnus-agent-fetch-group-1"
"gnus-agent-fetch-session"
"call-interactively"
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-06-15 15:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-27 15:06 How to debug out of memory situation? Kai Großjohann
2003-05-28 23:57 ` Richard Stallman
2003-06-09 17:23 ` Kai Großjohann
2003-06-15 15:59 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).