[LTP] min_free_kbytes.c:134: FAIL: child unexpectedly failed: 139

[Jan Stancek <jstancek@redhat.com>]

[adding back LTP list] Please keep the list CC-ed, you might get more responses
from other members.

----- Original Message -----
> (gdb) bt
> #0  0x0000003fe1713b92 in __vfscanf_internal (s=0x23000, format=<optimized
> out>, argptr=<optimized out>, mode_flags=<optimized out>) at
> vfscanf-internal.c:345
> Backtrace stopped: Cannot access memory at address 0xfffffffffffffff9

Which is unfortunate.

Only place I see child reaching vfscanf is via check_monitor -> get_sys_tune,
but per test output it's not check_monitor child, but eatup_mem one.

I don't see why it would crash here, and why it happens on RISCV only.
I can only recommend to try simplify the testcase to see what triggers it.

Is this the only LTP test you see crashing? 
Is it built natively on RISCV or is it cross-compiled in other environment?

> (gdb) where
> #0  0x0000003fe1713b92 in __vfscanf_internal (s=0x23000, format=<optimized
> out>, argptr=<optimized out>, mode_flags=<optimized out>) at
> vfscanf-internal.c:345
> Backtrace stopped: Cannot access memory at address 0xfffffffffffffff9
> 
> (gdb) info registers
> ra             0x16438 0x16438 <safe_waitpid+40>
> sp             0x3fffd94850 0x3fffd94850
> gp             0x29f10 0x29f10 <ipc_path+544>
> tp             0x3fe16cd720 0x3fe16cd720
> t0             0xffffffffffffffff -1
> t1             0x1366c 79468
> t2             0x1000 4096
> fp             0x1 0x1
> s1             0x180 384
> a0             0x180 384
> a1             0x3fffd948c4 274875369668
> a2             0xa 10
> a3             0x0 0
> a4             0x3fffd948c4 274875369668
> a5             0xffffffffffffffff -1
> a6             0x1 1
> a7             0x104 260
> s2             0x3fffd948c4 274875369668
> s3             0xa 10
> s4             0x79 121
> s5             0x3fe17e6008 274366095368
> s6             0x21ad0 137936
> s7             0x22000 139264
> s8             0x22000 139264
> s9             0x22000 139264
> s10            0x23000 143360
> s11            0x1fed70 2092400
> t3             0x3fe17e5790 274366093200
> t4             0x3fe17a2070 274365816944
> t5             0x3fe17a2970 274365819248
> t6             0x5 5
> pc             0x3fe1713b92 0x3fe1713b92 <__vfscanf_internal+1126>
> (gdb)
> 
> ________________________________
> Sent: Tuesday, February 25, 2020 1:03 PM
> Subject: Re: [LTP] min_free_kbytes.c:134: FAIL: child unexpectedly failed:
> 139
> 
> ----- Original Message -----
> 
> > Hi Jan,
> > i have tried to collect the core through GDB this is the result i
> > found??what
> > i should conclude from this??
> 
> Can you paste the output of backtrace? ('bt' command in gdb)
> 
> 
> > root@exaleapsemi:~/pankaj_ltpn/ltp/testcases/kernel/mem/tunable# gdb
> > ./min_free_kbytes core.378
> > GNU gdb (GDB) 8.3.1
> > Copyright (C) 2019 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 "riscv64-oe-linux".
> > 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 ./min_free_kbytes...
> > [New LWP 378]
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/libthread_db.so.1".
> > Core was generated by `./min_free_kbytes'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0 0x0000003fe1713b92 in __vfscanf_internal (s=0x23000, format=<optimized
> > out>, argptr=<optimized out>, mode_flags=<optimized out>) at
> > vfscanf-internal.c:345
>