13339 2019-05-08 13:42:13 +0000 Ruby 2.4.4 does not run with Apalis iMX6 2019-05-13 16:55:39 +0000 1 1 11 Runtime General Runtime General Runtime 2.6.2 Other arm RESOLVED MOVED Medium+ normal 2.8 M1 1 nam.whoelse mingli.yu randy.macleod ross.burton --- --- No (bug/feature does not impact docs) oldest_to_newest 83735 0 nam.whoelse 2019-05-08 13:42:13 +0000 Preconditions/Environment ------------------------- Yocto release: rocko (2.6.2) Additional layers: meta-freescale (rocko) meta-freescale-3rdparty (rocko) meta-toradex-bsp-common (rocko) meta-toradex-nxp (rocko) Image recipe: core-image-full-cmdline Additional package(s): connman connman-client, python3, ruby Additional configurations in local.conf: PACKAGE_CLASSES ?= "package_ipk" KERNEL_IMAGETYPE = "zImage" DISTRO_FEATURES_append = " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "systemd-compat-units" EXTRA_IMAGE_FEATURES += "package-management" Linux: Linux-toradex, kernel v4.9 Triggering Action/Cause ----------------------- running "ruby -v" from command line Expectation ----------- display the version of ruby installed Actual Result ------------- the program hangs. The only way to exit is to use keyboard interrupt Reproducibility --------------- 20/20 83736 1 nam.whoelse 2019-05-08 13:43:49 +0000 Hardware: Toradex Apalis iMX6 MACHINE = "apalis-imx6" 83773 2 ross.burton 2019-05-09 15:43:26 +0000 root@bob:~# ruby -v ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux-gnu] At least ruby for x86 in master works. Can you replicate this with master? Or in a qemu for a different machine? 83786 3 nam.whoelse 2019-05-10 14:19:01 +0000 Hi Ross, I have attempted to run the latest version of ruby 2.5.3. It still yields the same issue. I've built it with thud instead of rocko for this test. Now for qemu, I've done some digging and the platform I"m using does not seem to be supported by qemu. Best regards, Nam 83788 4 ross.burton 2019-05-10 15:15:35 +0000 Can you try your setup but with MACHINE=qemux86-64 in a qemu to see if it is your distro or your machine that is breaking? Also installing the debug symbols and attaching gdb would give a hint about where it is hanging. 83795 5 nam.whoelse 2019-05-13 13:44:50 +0000 Hi Ross, As you confirmed initially, it works in qemu mode (build with MACHINE=qemux86-64). I forgot to mention one thing. I'm building with the default poky distro. I've built the image again, but this time, adding debug tools and symbols by adding the following options in local.conf EXTRA_IMAGE_FEATURES += "tools-debug dbg-pkgs" it's confirmed during run time by running "opkg list | grep ruby" ruby - 2.4.4-r0 ruby-dbg - 2.4.4-r0 The debug symbols are installed by default as expected I tried to run "ruby -v" again and the program continues to hang. I proceeded with using gdb by running "gdb /usr/bin/ruby" Inside gdb mode, I invoke "run -v", the full output is as following: GNU gdb (GDB) 8.0 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-poky-linux-gnueabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/ruby...Reading symbols from /usr/bin/.debug/ruby...done. done. (gdb) run -v Starting program: /usr/bin/ruby -v [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". It also hangs inside gdb Best regards, Nam 83796 6 ross.burton 2019-05-13 13:47:09 +0000 When it hangs inside gdb, control-c it to interrupt and run 'bt' to get the stack trace. 83797 7 nam.whoelse 2019-05-13 14:44:07 +0000 Hi Ross, Here is the results from running "bt" (gdb) bt #0 syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37 #1 0x76e8e5d4 in fill_random_bytes_syscall (seed=seed@entry=0x7efff018, size=size@entry=16, need_secure=need_secure@entry=1) at /usr/src/debug/ruby/2.4.4-r0/ruby-2.4.4/random.c:525 #2 0x76e8f6a8 in fill_random_bytes (need_secure=1, size=16, seed=0x7efff018) at /usr/src/debug/ruby/2.4.4-r0/ruby-2.4.4/random.c:541 #3 fill_random_seed (seed=seed@entry=0x7efff018, cnt=4) at /usr/src/debug/ruby/2.4.4-r0/ruby-2.4.4/random.c:555 #4 0x76e90f90 in Init_RandomSeedCore () at /usr/src/debug/ruby/2.4.4-r0/ruby-2.4.4/random.c:1524 #5 0x76e2d8d4 in rb_call_inits () at /usr/src/debug/ruby/2.4.4-r0/ruby-2.4.4/inits.c:20 #6 0x76e0fcf8 in ruby_setup () at /usr/src/debug/ruby/2.4.4-r0/ruby-2.4.4/eval.c:60 #7 0x76e11270 in ruby_init () at /usr/src/debug/ruby/2.4.4-r0/ruby-2.4.4/eval.c:76 #8 0x00010728 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/ruby/2.4.4-r0/ruby-2.4.4/main.c:35 Nam 83798 8 ross.burton 2019-05-13 15:11:46 +0000 It's hanging trying to find enough random data to initialize. A workaround is to install rng-tools, but that's very much a workaround unless the hardware has a hardware random number generator that can be used. I'd approach toradex and check if there is a HW RNG, and if so how to enable it. As this is a toradex-specific bug and they don't use this bugzila, I'm closing this bug. 83801 9 nam.whoelse 2019-05-13 16:55:39 +0000 Hi Ross, Thanks for the info. Please let me know if there's anything I can do to help. Nam