[#87847] undefined symbol: mjit_init_p — Leam Hall <leamhall@...>

I pulled Ruby trunk on 3 Jul and am now getting errors similar to the

10 messages 2018/07/07

[#88088] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — normalperson@...

Issue #14937 has been reported by normalperson (Eric Wong).

9 messages 2018/07/24

[ruby-core:87751] [Ruby trunk Bug#14883] Ruby 2.5 Fails to Build on PowerPC 32-bit (BE)

From: lion@...
Date: 2018-07-02 15:07:11 UTC
List: ruby-core #87751
Issue #14883 has been updated by lion (Daming Yang).


I did some further investigation. It is a little bit longer story than I thought.

Firstly, the callstacks in Ruby shows that:
~~~
...
/root/ruby/lib/rdoc/parser/ripper_state_lex.rb:594:in `parse'
/root/ruby/lib/rdoc/parser/ripper_state_lex.rb:308:in `get_squashed_tk'
/root/ruby/lib/rdoc/parser/ripper_state_lex.rb:308:in `next'
(End of list)
~~~

I thought that might be a null pointer error but it wasn't. Ruby SEGVs, even for executing a simple Ruby program uses Enumerator.next.

~~~ ruby
# cat lion_each.rb
fib = Enumerator.new do |y|
  y << "FOO"
  y << "BAR"
end
fib.each do |s|
  puts s
end
~~~
is Good.

~~~ ruby
# cat lion_next.rb
fib = Enumerator.new do |y|
  y << "FOO"
  y << "BAR"
end
puts fib.next
~~~
Segmentation fault.

Now let us look at the C backtrace:
~~~
-- C level backtrace information -------------------------------------------
/root/ruby/ruby(rb_vm_bugreport+0xa0) [0x207f8908] vm_dump.c:703
/root/ruby/ruby(rb_bug_context+0xd8) [0x207ed7e8] error.c:580
/root/ruby/ruby(sigsegv+0x64) [0x206bd3c4] signal.c:928
linux-vdso32.so.1(0x100420) [0x100420]
[0x201a720c]
/root/ruby/ruby(rb_fiber_resume+0x294) [0x207c102c] vm_core.h:1691
/root/ruby/ruby(enumerator_next+0xe4) [0x207e67d4] enumerator.c:705
~~~
(According to the memory mapping, `0x201a720c` is in `libc.so`.)

I opted out the $optflags (dropped -O3) and I got a more detailed backtrace, showed that the failed C library function is at here:
https://github.com/ruby/ruby/blob/v2_5_1/cont.c#L827
~~~c
#else /* not WIN32 */
    ucontext_t *context = &fib->context;
    char *ptr;
    STACK_GROW_DIR_DETECTION;

    getcontext(context);
    ptr = fiber_machine_stack_alloc(size);
    context->uc_link = NULL;
    context->uc_stack.ss_sp = ptr;
    context->uc_stack.ss_size = size;
    fib->ss_sp = ptr;
    fib->ss_size = size;
    makecontext(context, rb_fiber_start, 0);  # !! HERE !!
    sec->machine.stack_start = (VALUE*)(ptr + STACK_DIR_UPPER(0, size));
    sec->machine.stack_maxsize = size - RB_PAGE_SIZE;
#endif
~~~

The `getcontext()` function was actually failed. I recompiled ruby with some modification to check the return value of `getcontext()`, it was -1 and `errno` was EPERM(1).
So now the direct reason of segmentation fault is clear and simple: `context` has not been filled with correct data, `makecontext()` tried to set and switch to an unknown "context", probably to read or execute on null pointers.

This bug was introduced at
~~~
commit c462c50d6336a0c7823ff8cfce51f8bff22eeff6
Author: ko1 <ko1@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>
Date:   Wed May 5 18:37:37 2010 +0000

    * cont.c: apply FIBER_USE_NATIVE patch.  This patch improve
      Fiber context switching cost using system APIs.  Detail comments
      are written in cont.c.
    
    git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@27635 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
~~~
from `v1_9_2_preview3`.

I compiled trunk (5235d57b0700c9f67892847d7f8fa055e98ca4d6, ahead of v2_6_0_preview2). It can still reproduce now, though it has moved to another place.
~~~
/root/ruby/miniruby(fiber_initialize_machine_stack_context+0x90) [0x20622a3c] cont.c:896
/root/ruby/miniruby(fiber_store+0x8c) [0x20623e04] cont.c:1668
/root/ruby/miniruby(fiber_switch+0x1d0) [0x2062411c] cont.c:1743
/root/ruby/miniruby(rb_fiber_resume+0xdc) [0x206244d0] cont.c:1824
...
~~~

# Conclusion

1. RDoc uses `Enumerator` and triggers this bug.
2. Due to some unknown reasons, the `getcontext()` failed,
3. thus Ruby could not create a fibre correctly.
4. Ruby switched to the malformed user context anyway, SEGV.

For more friendly error handling, I suggest we check the return value of `getcontext()`:
~~~c
if (getcontext(context) < 0) {
    rb_bug("can't get user context: %s", strerror(errno));
}
~~~

(Would you like to rephrase the title a little bit, Bai, wouldn't yeh?)  (O v O )

----------------------------------------
Bug #14883: Ruby 2.5 Fails to Build on PowerPC 32-bit (BE)
https://bugs.ruby-lang.org/issues/14883#change-72776

* Author: mingcongbai (Mingcong Bai)
* Status: Feedback
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 2.5.1
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
When building Ruby 2.5.1 on a PowerPC 32-bit (Big Endian) host, the build fails as it generates rdoc - segmentation fault. The build log is as follows:

https://pastebin.aosc.io/paste/jJWjWPadcmJeLEkvpgnMqQ

Configure parameters...

... \
    --enable-shared \
    --disable-rpath \
    --with-dbm-type=gdbm_compat

On the same host with the same build environment, Ruby 2.4 builds just fine. The current Git master exhibits the same issue.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next