[Pkg-erlang-devel] Bug#939804: Bug#939804: erlang: FTBFS on hppa - escript: exception error: bad argument

[Sergei Golovan]

Hi John,

On Tue, Sep 10, 2019 at 4:58 AM John David Anglin <dave.anglin at bell.net> wrote:
>
> I added some printfs to the code.
>
> thr_wrapper: stacksize=0x0
> thr_wrapper: stacksize=0x0
> thr_wrapper: stacksize=0x0
> thr_wrapper: stacksize=0x10000
> thr_wrapper: stacksize=0x10000
> thr_wrapper: stacksize=0x10000
> erts_init_bif_re: &c=0xf9730748 ERTS STACK LIMIT=0x0
> erts_init_bif_re: &c=0xf9df6748 ERTS STACK LIMIT=0x0
> erts_init_bif_re: &c=0xf90b0748 ERTS STACK LIMIT=0x0
> erts_init_bif_re: &c=0xf908c748 ERTS STACK LIMIT=0x0

This seems to cause the issue since stack limit 0x0 means that it's still
uninitialized, but it's used in a comparison which determines the
direction of stack.

>
> It would seem to me that ERTS_STACK_LIMIT is incorrect.  As a result, stack_guard_downwards
> is called instead of stack_guard_upwards.
>
> It's also a bit odd that  twd->stacksize in thr_wrapper is sometimes 0.  Think ethr_thr_create
> needs looking at.

May be. As a quick fix I can suggest a separate check for the stack
direction in erl_bif_re.c, here's a patch.

--- a/erts/emulator/beam/erl_bif_re.c
+++ b/erts/emulator/beam/erl_bif_re.c
@@ -90,6 +90,15 @@
     return erts_check_above_limit(&c, limit - ERTS_PCRE_STACK_MARGIN);
 }

+__attribute__((noinline)) static int stack_grows_downwards(char *prev_c)
+{
+    char c;
+    if (&c < prev_c)
+        return 1;
+    else
+        return 0;
+}
+
 void erts_init_bif_re(void)
 {
     char c;
@@ -97,7 +106,7 @@
     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)
+    if (stack_grows_downwards(&c))
         erts_pcre_stack_guard = stack_guard_downwards;
     else
         erts_pcre_stack_guard = stack_guard_upwards;

I don't think it can be accepted upstream as a permanent fix though. I
think it'd
be better to fix the stack limit initialization somehow.

Cheers!
-- 
Sergei Golovan