Termux-app: GNU wget 1.20 Segmentation Fault Fire Tv

Created on 16 Dec 2018 · 16Comments · Source: termux/termux-app

I'm running Termux on a new Fire TV Cube. When running GNU wget 1.20, the requested file downloads successfully, however after the successful download it throws a segmentation fault. It does successfully save what appears to be an uncorrupted file to disk before the segmentation fault.

In isolation this isn't a problem, however it causes bash scripts that rely on wget (like the setupTermuxArch.sh script from @sdrausty) to fail midstream.

Source

JeffVandrewJr

All 16 comments

Can you provide a link that 100% fails ?
I'm unable to reproduce this issue on ARM android 6 and AArch64 android 8.

xeffyr on 16 Dec 2018

@xeffyr Sure. wget https://raw.githubusercontent.com/sdrausty/TermuxArch/master/setupTermuxArch.sh will download perfectly as I mentioned, but then will get a segmentation fault.

Then when I run setupTermuxArch.sh, the bash script bails after the first wget command due to segmentation fault.

JeffVandrewJr on 16 Dec 2018

@JeffVandrewJr what's your output of termux-info?

Grimler91 on 16 Dec 2018

@Grimler91

All packages up to date.

System information:

Linux localhost 3.14.29 #1 SMP PREEMPT Thu Nov 29 08:10:14 UTC 2018 armv81 Android

Termux-packages arch:
arm

Android Version:
7.1.2

Device Manufacturer:
Amazon

Device Model:
AFTA

JeffVandrewJr on 16 Dec 2018

@xeffyr Sure. wget https://raw.githubusercontent.com/sdrausty/TermuxArch/master/setupTermuxArch.sh will download perfectly as I mentioned, but then will get a segmentation fault.

Still no segfault (on AArch64):

$ wget https://raw.githubusercontent.com/sdrausty/TermuxArch/master/setupTermuxArch.sh
--2018-12-16 18:11:16--  https://raw.githubusercontent.com/sdrausty/TermuxArch/master/setupTermuxArch.sh
Resolving raw.githubusercontent.com... 151.101.112.133
Connecting to raw.githubusercontent.com|151.101.112.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 30563 (30K) [text/plain]
Saving to: ‘setupTermuxArch.sh’

setupTermuxArch.sh  100%[===================>]  29.85K  --.-KB/s    in 0.05s   

2018-12-16 18:11:17 (569 KB/s) - ‘setupTermuxArch.sh’ saved [30563/30563]

$

xeffyr on 16 Dec 2018

On ARM got segfault. But only on link https://raw.githubusercontent.com/sdrausty/TermuxArch/master/setupTermuxArch.sh.

xeffyr on 16 Dec 2018

👍1

@xeffyr If you run that bash script, you should so get a seg fault on the first wget it calls.

JeffVandrewJr on 16 Dec 2018

@Grimler91 Have you tried to build debug version of wget ? I'm getting error even on clean docker image:

In file included from /home/builder/.termux-build/wget/src/lib/regex.c:68:
In file included from /home/builder/.termux-build/wget/src/lib/regex_internal.h:25:
In file included from ./stdio.h:43:
In file included from /home/builder/.termux-build/_cache/18-arm-21-v1/bin/../sysroot/usr/include/stdio.h:334:
/home/builder/.termux-build/_cache/18-arm-21-v1/bin/../sysroot/usr/include/bits/fortify/stdio.h:56:46: error: use of undeclared identifier '__USE_FORTIFY_LEVEL'
    return __builtin___vsprintf_chk(dest, 0, __bos(dest), format, ap);
                                             ^
/home/builder/.termux-build/wget/src/lib/cdefs.h:123:48: note: expanded from macro '__bos'
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)
                                               ^
In file included from /home/builder/.termux-build/wget/src/lib/regex.c:68:
In file included from /home/builder/.termux-build/wget/src/lib/regex_internal.h:25:
In file included from ./stdio.h:43:
In file included from /home/builder/.termux-build/_cache/18-arm-21-v1/bin/../sysroot/usr/include/stdio.h:334:
/home/builder/.termux-build/_cache/18-arm-21-v1/bin/../sysroot/usr/include/bits/fortify/stdio.h:68:17: error: use of undeclared identifier '__USE_FORTIFY_LEVEL'
    __enable_if(__bos(dest) != __BIONIC_FORTIFY_UNKNOWN_SIZE &&
                ^
/home/builder/.termux-build/wget/src/lib/cdefs.h:123:48: note: expanded from macro '__bos'
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)
                                               ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
  CC       spawn.o
  CC       spawn_faction_addclose.o
20 errors generated.
make[4]: *** [Makefile:2306: regex.o] Error 1
make[4]: *** Waiting for unfinished jobs....

Build command was ./build-package.sh -d -a arm wget.

xeffyr on 16 Dec 2018

@xeffyr yeah, I got the same. Removing the fortify flag in termux_step_pre_configure (as we do for, for example, nano) makes it build

Grimler91 on 17 Dec 2018

I've uploaded a build for arm here: wget https://grimler.se/dists/testing/debug/binary-arm/wget-dbg_1.20_arm.deb.

A gdb backtrace isn't very exciting though, we might need to build debug variant of openssl as well:

(gdb) run
Starting program: /data/data/com.termux/files/usr/bin/wget https://raw.githubusercontent.com/sdrausty/TermuxArch/master/setupTermuxArch.sh

Program received signal SIGILL, Illegal instruction.
0xb6dcd406 in ?? () from /data/data/com.termux/files/usr/lib/libcrypto.so.1.1
(gdb) bt
#0  0xb6dcd406 in ?? () from /data/data/com.termux/files/usr/lib/libcrypto.so.1.1
#1  0xb6dcd2fe in ?? () from /data/data/com.termux/files/usr/lib/libcrypto.so.1.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Grimler91 on 17 Dec 2018

Seems the issue is in openssl, with a openssl debug build as well I get:

(gdb) r
Starting program: /data/data/com.termux/files/usr/bin/wget https://raw.githubusercontent.com/sdrausty/TermuxArch/master/setupTermuxArch.sh

Program received signal SIGILL, Illegal instruction.
0xb6cd9386 in _armv7_tick () from /data/data/com.termux/files/usr/lib/libcrypto.so.1.1
(gdb) bt
#0  0xb6cd9386 in _armv7_tick () from /data/data/com.termux/files/usr/lib/libcrypto.so.1.1
#1  0xb6cd9280 in OPENSSL_cpuid_setup () at crypto/armcap.c:202
#2  0xb6f9e506 in __dl__ZN6soinfo13call_functionEPKcPFvvE () from /system/bin/linker
#3  0xb6f9e428 in __dl__ZN6soinfo10call_arrayEPKcPPFvvEjb () from /system/bin/linker
#4  0xb6f9d112 in __dl__ZN6soinfo17call_constructorsEv () from /system/bin/linker
#5  0xb6f9d0ae in __dl__ZN6soinfo17call_constructorsEv () from /system/bin/linker
#6  0xb6f9d0ae in __dl__ZN6soinfo17call_constructorsEv () from /system/bin/linker
#7  0xb6fa1b5e in __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockj () from /system/bin/linker
#8  0xb6fa0fb6 in __dl___linker_init () from /system/bin/linker
#9  0xb6f9a7c4 in __dl__start () from /system/bin/linker
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

deb available here: https://grimler.se/dists/testing/debug/binary-arm/openssl-dbg_1.1.1a_arm.deb

Grimler91 on 17 Dec 2018

About openssl - see https://stackoverflow.com/questions/25708907/ssl-library-init-cause-sigill-when-running-under-gdb. This is not a bug.

It is normal behavior in startup code as the library tests for processor features. You can safely ignore it by issuing 'handle SIGILL nostop'.

xeffyr on 17 Dec 2018

Backtrace:

(gdb) bt
#0  0x7f585540 in rpl_fseeko (fp=0xb6bbdeac <usual>, offset=0,
    whence=0) at /storage/termux-build/wget/src/lib/fseeko.c:75
#1  0x7f5672ba in hsts_store_save (store=0xb69e6000,
    filename=0xb69de000 "/data/data/com.termux/files/home/.wget-hsts")
    at /storage/termux-build/wget/src/src/hsts.c:576
#2  0x7f571f2a in save_hsts ()
    at /storage/termux-build/wget/src/src/main.c:222
#3  0x7f57185c in main (argc=2136545111, argv=0x7f5956eb)
    at /storage/termux-build/wget/src/src/main.c:2287
(gdb)

xeffyr on 17 Dec 2018

this is the same bug in gnulib from coreutils.