On 2019-09-09 9:12 a.m., Sergei Golovan wrote: > Hi John, > > On Mon, Sep 9, 2019 at 2:13 PM John David Anglin <dave.ang...@bell.net> wrote: >> If you know how to reduce one of these regexp problems, I could look again. >> Debugging >> across forks is problematic (i.e., the error doesn't occur in escript). > I seem to find the problematic code. If you look into > erts/emulator/beam/erl_bif_re.c then > you'll find the following lines after line 66: > > #define ERTS_PCRE_STACK_MARGIN (10*1024) > > # define ERTS_STACK_LIMIT ((char *) ethr_get_stacklimit()) > > static int > stack_guard_downwards(void) > { > char *limit = ERTS_STACK_LIMIT; > char c; > > ASSERT(limit); > > return erts_check_below_limit(&c, limit + ERTS_PCRE_STACK_MARGIN); > } > > static int > stack_guard_upwards(void) > { > char *limit = ERTS_STACK_LIMIT; > char c; > > ASSERT(limit); > > return erts_check_above_limit(&c, limit - ERTS_PCRE_STACK_MARGIN); > } > > void erts_init_bif_re(void) > { > char c; > erts_pcre_malloc = &erts_erts_pcre_malloc; > erts_pcre_free = &erts_erts_pcre_free; > erts_pcre_stack_malloc = &erts_erts_pcre_stack_malloc; > erts_pcre_stack_free = &erts_erts_pcre_stack_free; > if ((char *) erts_ptr_id(&c) > ERTS_STACK_LIMIT) > erts_pcre_stack_guard = stack_guard_downwards; > else > erts_pcre_stack_guard = stack_guard_upwards; > default_table = NULL; /* ISO8859-1 default, forced into pcre */ > max_loop_limit = CONTEXT_REDS * LOOP_FACTOR; > > erts_init_trap_export(&re_exec_trap_export, am_erlang, am_re_run_trap, 3, > &re_exec_trap); > > grun_trap_exportp = erts_export_put(am_re,am_grun,3); > urun_trap_exportp = erts_export_put(am_re,am_urun,3); > ucompile_trap_exportp = erts_export_put(am_re,am_ucompile,2); > > return; > } > > The code > > if ((char *) erts_ptr_id(&c) > ERTS_STACK_LIMIT) > erts_pcre_stack_guard = stack_guard_downwards; > else > erts_pcre_stack_guard = stack_guard_upwards; > > has been introduces in version 20, and it is used to protect stack > during PCRE calls. > It seems that this stack protection doesn't work for hppa and always > fails. As a result, > every call to a regexp routine fails. The calls fail with quit an obscure error. > > After I remove the erts_pcre_stack_guard assignment, Erlang started to > build on hppa > just fine. > > Unfortunately, I don't know anything about stack in hppa architecture, > so I can't offer > a proper fix in this case. > > I hope this'll help in debugging and developing a fix. Awesome!
Stacks grows up on hppa, so this explains why only hppa fails. Within gcc, there is no stack protection for stacks that grow up. Glibc provides a guard for each stack at upper end. Kernel grows main stack dynamically. Initial allocation for main stack is fairly small. I'll look at code tonight. I wonder if limit is correct (ERTS_STACK_LIMIT). Dave -- John David Anglin dave.ang...@bell.net