[U-Boot] Travis test/py sandbox_spl test fail【请注意，邮件由sjg at google.com代发】

Tue Sep 17 05:06:01 UTC 2019

Hi Kever,

On Thu, 29 Aug 2019 at 02:27, Kever Yang <kever.yang at rock-chips.com> wrote:
>
>
> On 2019/8/24 下午12:19, Simon Glass wrote:
>
> Hi Kever,
>
> On Mon, 19 Aug 2019 at 19:53, Kever Yang <kever.yang at rock-chips.com> wrote:
>
> Hi Stephen,
>
> On 2019/8/20 上午1:34, Stephen Warren wrote:
>
> On 8/18/19 7:01 PM, Kever Yang wrote:
>
> Hi Simon, Stephen,
>
>      Could you help to comment on my other mail, which patch cause
> this failure.
>
> If you run "git bisect", you should be able to track down which patch
> introduced the problem.
>
> I already locate the patch,  and it seems some but in sandbox_spl or
> test, but not the driver,
>
> see below:
>
> https://patchwork.ozlabs.org/patch/1100742/
>
> Here's what I found:
>
> $ gdb --args /tmp/b/sandbox_spl/u-boot -D
> GNU gdb (Debian 8.1-4+build1) 8.1
> Copyright (C) 2018 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 "x86_64-linux-gnu".
> 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 /tmp/b/sandbox_spl/u-boot...done.
> (gdb) r
> Starting program: /tmp/b/sandbox_spl/u-boot -D
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> bloblist_init() Existing bloblist not found: creating new bloblist
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000555555617db5 in strcmp (cs=cs at entry=0x5555556602cf "root_driver",
>     ct=0x1 <error: Cannot access memory at address 0x1>)
>     at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190
> 190 if ((__res = *cs - *ct++) != 0 || !*cs++)
> (gdb) up
> #1  0x00005555555a9f91 in lists_driver_lookup_name
> (name=0x5555556602cf "root_driver")
>     at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28
> 28 if (!strcmp(name, entry->name))
> (gdb) print entry->name
> $1 = 0x0
> (gdb) print *entry
> $2 = {name = 0x0, id = UCLASS_ROOT, of_match = 0x0, bind =
> 0x55555569b660, probe = 0x3e,
>   remove = 0x5555556fd1e0 <rk8xx_ids>, unbind = 0x5555555d0ad6 <rk8xx_bind>,
>   ofdata_to_platdata = 0x5555555d0a77 <rk8xx_probe>, child_post_bind =
> 0x0, child_pre_probe = 0x0,
>   child_post_remove = 0x0, priv_auto_alloc_size = 0,
> platdata_auto_alloc_size = 0,
>   per_child_auto_alloc_size = 0, per_child_platdata_auto_alloc_size =
> 0, ops = 0x0, flags = 4}
>
>
> Here you have a rockchip driver in UCLASS_ROOT with no name.
>
> The symbol is _u_boot_list_2_driver_2_pmic_rk8xx so perhaps it is
> getting corrupted?
>
>
> But I don't understand how this corrupt happen, does this area should be RO data?
> When I compare the good case and error case, I got below difference, the 'fill' data
> only present at error case, does it suppose to be there?
>
>  .u_boot_list_2_driver_2_pmic_pm8916
>                 0x00000000003b14f0       0x78 drivers/power/pmic/built-in.o
>                 0x00000000003b14f0                _u_boot_list_2_driver_2_pmic_pm8916
>  *fill*         0x00000000003b1568       0x18
>  .u_boot_list_2_driver_2_pmic_rk8xx
>                 0x00000000003b1580       0x78 drivers/power/pmic/built-in.o
>                 0x00000000003b1580                _u_boot_list_2_driver_2_pmic_rk8xx
>
>
> Thanks,
> - Kever

I don't understand it either.

It should be possible to see it by setting a watchpoint on an address
that is getting corrupted.

I haven't made time to look at this further.

Regards,
Simon

>
> (gdb) where
> #0  0x0000555555617db5 in strcmp (cs=cs at entry=0x5555556602cf "root_driver",
>     ct=0x1 <error: Cannot access memory at address 0x1>)
>     at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190
> #1  0x00005555555a9f91 in lists_driver_lookup_name
> (name=0x5555556602cf "root_driver")
>     at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28
> #2  0x00005555555a9561 in device_bind_by_name (parent=parent at entry=0x0,
>     pre_reloc_only=pre_reloc_only at entry=false,
> info=info at entry=0x5555556fa560 <root_info>,
>     devp=0x7fffffffdd08) at
> /home/sjg/c/src/third_party/u-boot/files/drivers/core/device.c:250
> #3  0x00005555555aa423 in dm_init (of_live=<optimized out>)
>     at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:148
> #4  0x00005555555aa558 in dm_init_and_scan
> (pre_reloc_only=pre_reloc_only at entry=true)
>     at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:373
> #5  0x000055555559381a in initf_dm () at
> /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:807
> #6  0x000055555559395a in initcall_run_list
> (init_sequence=0x5555556fe840 <init_sequence_f>)
>     at /home/sjg/c/src/third_party/u-boot/files/include/initcall.h:38
> #7  board_init_f (boot_flags=<optimized out>)
>     at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:986
> #8  0x00005555555774d6 in main (argc=2, argv=0x7fffffffdf58)
>     at /home/sjg/c/src/third_party/u-boot/files/arch/sandbox/cpu/start.c:360
> (gdb) q
>
>
>
> Regards,
> Simon
>