Re: gnus crashes XEmacs (on MacOS X 10.0.1) in summary buffer
Simon Josefsson <simon(a)josefsson.org> writes:
Eric Knauel <eric(a)macnews.de> writes:
> strange thing happen with my Oort Gnus. After opening the summary
> buffer for nnml:mail.misc I simply press "n" to get to the
> messages. That's all, XEmacs 21.2.46 crashes immediatly. I can
> reproduce the crash, but I'm not sure if it is still reproducable
> after reading the mail. ;-)
Could you try XEmacs 21.4.0?
Anyway, this is most likely a XEmacs problem, so I've CC'd
xemacs-beta, maybe someone there can tell something from the backtrace
below.
> Program received signal EXC_BAD_ACCESS, Could not access memory.
^^^^^^^^^^^^^^
what kind of a signal is that? is that like a SEGV?
> 0x00158e60 in re_match_2_internal (bufp=warning:
> ppc_frame_chain_valid: stack frame from 0xbffada70 to 0xbfffdd40
> larger than 65536 bytes; assuming invalid
maybe you are hitting a limit of the size of the stack similar to what
we often see on DEC OSF and OpenBSD. See the following entry from our
PROBLEMS file.
,----
| ** Digital UNIX/OSF/VMS/Ultrix
| *** XEmacs crashes on Digital Unix within font-lock, or when dealing
| with large compilation buffers.
|
| The default stack size under Digital Unix is rather small (2M as
| opposed to Solaris 8M), hosing the regexp code, which uses alloca()
| extensively, overflowing the stack when complex regexps are used.
| Workarounds:
|
| 1) Increase your stack size, using `ulimit -s 8192' or a (t)csh
| equivalent;
|
| 2) Recompile regex.c with REGEX_MALLOC defined.
`----
what is the default stack size on your OS?
Gunnar