11:30 a.m.
Last week I asked about XEmacs-21.4.0 crashing on Digital Unix and
Gunnar Evermann pointed out that this problem is already reported
in PROBLEMS file. As Stephen just told that bug reports should be
preferably sent to xemacs-beta list, below is copy of article sent
to comp.emacs.xemacs few days ago. And my question is that should
the REGEX_MALLOC definition work?
"Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes:
Gunnar> maybe this entry from the PROBLEMS file helps:
Gunnar> ** Digital UNIX/OSF/VMS/Ultrix
Gunnar> *** XEmacs crashes on Digital Unix within font-lock, or when dealing
Gunnar> with large compilation buffers.
Yes, this entry describes the problem, but...
Gunnar> 1) Increase your stack size, using `ulimit -s 8192' or a (t)csh
Gunnar> equivalent;
In our current environment it is not easy to set this for our all
users. Moreover, it would not prevent crashing, just make it more
unprobable. So I would prefer other solution...
Gunnar> 2) Recompile regex.c with REGEX_MALLOC defined.
I configured with --cppflags=-DREGEX_MALLOC but...
gcc -c -O3 -I. -I../src -I/proj/ave/xemacs/xemacs-21.4.0/lib-src
-I/proj/ave/xemacs/xemacs-21.4.0/src -DREGEX_MALLOC -DHAVE_CONFIG_H -I/usr/local/include
\
-DINHIBIT_STRING_HEADER /proj/ave/xemacs/xemacs-21.4.0/src/regex.c
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c: In function `sys_re_compile_fastmap':
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3412: `DECLARE_NOTHING' undeclared (first
use this function)
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3412: (Each undeclared identifier is reported
only once
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3412: for each function it appears in.)
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3415: parse error before `char'
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3439: `fastmap' undeclared (first use this
function)
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3445: `p' undeclared (first use this
function)
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3445: `pend' undeclared (first use this
function)
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3450: `path_can_be_null' undeclared (first
use this function)
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3822: `succeed_n_p' undeclared (first use
this function)
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c: In function `re_match_2_internal':
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:5053: `DECLARE_NOTHING' undeclared (first
use this function)
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:5053: parse error before `int'
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:5053: `this_reg' undeclared (first use this
function)
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:5204: parse error before `int'
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:5257: parse error before `int'
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:5460: parse error before `int'
/proj/ave/xemacs/xemacs-21.4.0/src/regex.c:5473: parse error before `int'
make[1]: *** [regex.o] Error 1
make[1]: Leaving directory
`/tmp_mnt/chaos.lce.hut.fi/proj/ave/ave/xemacs/build/alpha-dec-osf4.0/lib-src'
make: *** [lib-src] Error 2
Aki
9:06 a.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
"Aki" == Aki Vehtari <Aki.Vehtari(a)hut.fi> writes 2001-04-25:
Aki> I configured with --cppflags=-DREGEX_MALLOC but...
Aki> gcc -c -O3 -I. -I../src -I/proj/ave/xemacs/xemacs-21.4.0/lib-src
-I/proj/ave/xemacs/xemacs-21.4.0/src -DREGEX_MALLOC -DHAVE_CONFIG_H -I/usr/local/include
\
Aki> -DINHIBIT_STRING_HEADER /proj/ave/xemacs/xemacs-21.4.0/src/regex.c
Aki> /proj/ave/xemacs/xemacs-21.4.0/src/regex.c: In function
`sys_re_compile_fastmap':
Aki> /proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3412: `DECLARE_NOTHING' undeclared
(first use this function)
Oh well, as no-one have looked into this yet, today I finally had
time myself to investigate this.
Problem is that DECLARE_NOTHING is undeclared, although lisp.h,
which defines it, is included. I copied following lines
from lisp.h
---Clip---
#ifndef DECLARE_NOTHING
#define DECLARE_NOTHING struct nosuchstruct
#endif
---Clip---
to regex.c, just before DECALRE_NOTHING is first time used,
and now I it compiled.
As I can't find reason why DECALRE_NOTHING is not defined, although
lisp.h, which defines it, is included, I hope that someone more
familiar with this part of the code would check where the problem
really is.
Btw, I also think that REGEX_MALLOC should be defined by default
for Digital UNIX.
Aki
10:09 a.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
>>>> "Ave" == Aki Vehtari
<Aki.Vehtari(a)hut.fi> writes:
Aki> gcc -c -O3 -I. -I../src -I/proj/ave/xemacs/xemacs-21.4.0/lib-src
Ave> Problem is that DECLARE_NOTHING is undeclared, although
Ave> lisp.h, which defines it, is included.
lisp.h isn't included when compiling for lib-src (eg, etags). I will
probably work up a patch and add this to src/regex.c as you suggest,
but along with other declarations that are needed when lisp.h doesn't
get included.
Ave> Btw, I also think that REGEX_MALLOC should be defined by
Ave> default for Digital UNIX.
I don't know about this; can you explain more?
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
11:28 a.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Ave> Btw, I also think that REGEX_MALLOC should be defined by
Ave> default for Digital UNIX.
I don't know about this; can you explain more?
I do. Digital Unix has a small default for stack segment, so XEmacs
crashes in regexp-heavy Lisp apps like Gnus and possibly font-lock.
The solution is to either increase the stack size with `ulimit', or to
make things work by default by defining REGEX_MALLOC, which makes
regexp.c use malloc rather than alloca.
Defining REGEX_MALLOC is not a perfect solution, though, because some
people suspect it to leak, and it makes regexps slower. Therefore:
A third, and IMHO best, solution would be for XEmacs to raise its own
stack size if it notices it to be too small. It's quite easy to do
for someone who has access to a Digital Unix system.
8:10 p.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
"Hrvoje" == Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
Hrvoje> A third, and IMHO best, solution would be for XEmacs to raise its own
Hrvoje> stack size if it notices it to be too small. It's quite easy to do
Hrvoje> for someone who has access to a Digital Unix system.
I think that once again Hrvoje is right. Althouh I have access to
Digital Unix system I'm afraid that fix is not easy enough that I
could do it, but I can try if no-one else will. For start, should
the stack size be checked when starting XEmacs or can stack size be
increased just when it has been exceeded?
Aki
1:46 a.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
"Hrvoje" == Hrvoje Niksic <hniksic(a)arsdigita.com>
writes:
Hrvoje> A third, and IMHO best, solution would be for XEmacs to raise its
own
Hrvoje> stack size if it notices it to be too small. It's
quite easy to
do
Hrvoje> for someone who has access to a Digital Unix system.
I think that once again Hrvoje is right. Althouh I have access to
Digital Unix system I'm afraid that fix is not easy enough that I
could do it, but I can try if no-one else will. For start, should
the stack size be checked when starting XEmacs or can stack size be
increased just when it has been exceeded?
I'm not sure if you can raise the stack size once your program has started.
I know that you can do it for threads on digital unix very simply. We could
put code like this where appropriate.
static int __check_stack_requirements(int necessary)
{
#ifdef RLIMIT_STACK
struct rlimit rl;
if (getrlimit(RLIMIT_STACK,&rl) == 0)
{
if (rl.rlim_cur >= necessary)
{
/* Everything will work just fine... */
return (0);
}
if (rl.rlim_max < necessary)
{
/* Maximum stack size is still too small...
** Should we just fail to start?
*/
return (-1);
}
rl.rlim_cur = necessary;
if (setrlimit(RLIMIT_STACK, &rl))
{
/* Error when setting new stack size... */
return (-1);
}
return (0);
#else
return (0);
#endif
}
and then do something like:
if (__check_stack_requirements(min_required_by_regex_c))
{
stderr_out ("Your regexps will be hosed...\n");
abort();
}
-bp
7:50 p.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
William M Perry <wmperry(a)aventail.com> writes:
I'm not sure if you can raise the stack size once your
program has started. I know that you can do it for threads
on digital unix very simply. We could put code like this
where appropriate.
static int __check_stack_requirements(int necessary)
{
#ifdef RLIMIT_STACK
struct rlimit rl;
if (getrlimit(RLIMIT_STACK,&rl) == 0)
{
if (rl.rlim_cur >= necessary)
/* Everything will work just fine... */
return (0);
}
if (rl.rlim_max < necessary)
{
/* Maximum stack size is still too small...
** Should we just fail to start?
*/
return (-1);
}
How can you know how much is necessary? In my case the stack overflow
occurred when opening BibTeX-file with long abstract fields. It's
not possible to know beforehand how long abstracts there might be.
And please no failing, I'd prefer just a warning like with REGEXP_MALLOC:
itimer "itimer-<1>" signaled: (error "Stack overflow in regexp
matcher")
Aki
3:51 a.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> A third, and IMHO best, solution would be for XEmacs to
Hrvoje> raise its own stack size if it notices it to be too small.
Hrvoje> It's quite easy to do for someone who has access to a
Hrvoje> Digital Unix system.
I do, but ... I have no idea whether the necessary tools are installed
(eg, gcc is 2.7.2.1). I know there's no cvs, I'll get back to you on
whether I can build xemacs at all later.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:55 a.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> A third, and IMHO best, solution would be for XEmacs to
Hrvoje> raise its own stack size if it notices it to be too small.
Hrvoje> It's quite easy to do for someone who has access to a
Hrvoje> Digital Unix system.
I should be able to build a CVS version of xemacs on Compaq Tru64 UNIX
V5.0A. GCC is 2.95.3. I may also be able to build on Digital UNIX
V4.0D, but it's not certain, because all necessary tools may not work
on that platform here. (Just because some of our local tools may have
been built on 5.0, and may not run on 4.0.)
Would this be helpful? All I can do is build, and test if someone
tells me specifically what to test. I'm not qualified to touch the
source code.
I'd like to contribute if I can, because I know (first hand) how
confusing the absurdly small default stacksize limit can be for
inexperienced Digital UNIX users.
Note that default (DFLSSIZ in /usr/include/machines/vmparam.h I think)
was increased from 2048KB in Digital UNIX 4.0 to 8192KB in Tru64 UNIX
5.0. Is it still a problem for xemacs with the larger default stack
size in 5.0?
Since it's sooooo easy for the user to solve this problem with ulimit,
wouldn't an entry in the PROBLEMS file be good enough?
(Apologies if I'm on the wrong track here. I did not study some
earlier messages in this thread very carefully, and have made some
assumptions about what I think you're all talking about.)
Kind regards,
David
-------------------------------------------------------------------
David Starks-Browning | starksb(a)ebi.ac.uk
EMBL Outstation -- |
The European Bioinformatics Institute |
Wellcome Trust Genome Campus | tel: +44 (1223) 494 616
Hinxton, Cambridge, CB10 1SD, UK | fax: +44 (1223) 494 468
-------------------------------------------------------------------
12:30 p.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
David Starks-Browning <starksb(a)ebi.ac.uk> writes:
Since it's sooooo easy for the user to solve this problem with
ulimit,
wouldn't an entry in the PROBLEMS file be good enough?
Haven't you looked? It's been there for ages!
** 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.
People don't read PROBLEMS. People prefer programs that work, and I
can understand that sentiment. It should be really easy to increase
the stack size programatically.
6:19 a.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> People don't read PROBLEMS. People prefer programs that work, and I
Hrvoje> can understand that sentiment. It should be really easy to increase
Hrvoje> the stack size programatically.
Agreed.
The stack size should be automatically increased.
Doing it portably requires some autoconfing, etc.
OSF aka Digital Unix aka Tru64 has a low stack size (2MB), but MacOS X
has an insanely low stack size (512kb), especially considering there
are no backward compatibility considerations.
12:29 p.m.
New subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC
Martin Buchholz <martin(a)xemacs.org> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> People don't read PROBLEMS. People prefer programs that work, and I
Hrvoje> can understand that sentiment. It should be really easy to increase
Hrvoje> the stack size programatically.
Agreed.
The stack size should be automatically increased.
Doing it portably requires some autoconfing, etc.
OSF aka Digital Unix aka Tru64 has a low stack size (2MB), but MacOS X
has an insanely low stack size (512kb), especially considering there
are no backward compatibility considerations.
just for reference, in case somebody gets around to implementing &
testing this: There were some reports of problems on OpenBSD as well.
I think their default limit is 2MB.
Gunnar
8580
days inactive
8612
days old
11 comments
7 participants
participants (7)
-
Aki Vehtari -
David Starks-Browning -
Gunnar Evermann -
Hrvoje Niksic -
Martin Buchholz -
Stephen J. Turnbull -
William M. Perry