[U-Boot] Travis test/py sandbox_spl test fail

[U-Boot] Travis test/py sandbox_spl test fail

[Kever Yang]

Hi Simon,

     I got fail in test/py sandbox_spl, and the log says:

E OSError: [Errno 5] Input/output error

I have no idea about what's wrong in source code, could you help

to take a look?

Travis job:

https://travis-ci.org/keveryang/u-boot/jobs/571125119


Thanks,

- Kever

[U-Boot] Travis test/py sandbox_spl test fail

[Simon Glass]

+Stephen

Hi Kever,

On Tue, 13 Aug 2019 at 03:35, Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Hi Simon,
>
>     I got fail in test/py sandbox_spl, and the log says:
>
> E OSError: [Errno 5] Input/output error
>
> I have no idea about what's wrong in source code, could you help
>
> to take a look?
>
> Travis job:
>
> https://travis-ci.org/keveryang/u-boot/jobs/571125119

When I've seen this (ugly) error it is normally because U-Boot
crashed, e.g. with a segfault.

It is maybe possible that a unicode character is being split over a
1024-byte boundary. I had to fix that behaviour in buildman (using
binary files and the 'bytes' type).

Regards,
Simon

[U-Boot] Travis test/py sandbox_spl test fail

[Stephen Warren]

On 8/13/19 3:39 AM, Simon Glass wrote:
> +Stephen
> 
> Hi Kever,
> 
> On Tue, 13 Aug 2019 at 03:35, Kever Yang <kever.yang@rock-chips.com> wrote:
>>
>> Hi Simon,
>>
>>      I got fail in test/py sandbox_spl, and the log says:
>>
>> E OSError: [Errno 5] Input/output error
>>
>> I have no idea about what's wrong in source code, could you help
>>
>> to take a look?
>>
>> Travis job:
>>
>> https://travis-ci.org/keveryang/u-boot/jobs/571125119
> 
> When I've seen this (ugly) error it is normally because U-Boot
> crashed, e.g. with a segfault.

Yes, that's the typical reason. If you run test.py locally you'll be 
able to access the log file (which Travis doesn't save), which will 
likely give you more details about the crash, and/or you could attach 
gdb to the sandbox process to trap the problem too.

[U-Boot] Travis test/py sandbox_spl test fail

[Kever Yang]

Hi Stephen,

On 2019/8/14 上午4:54, Stephen Warren wrote:
> On 8/13/19 3:39 AM, Simon Glass wrote:
>> +Stephen
>>
>> Hi Kever,
>>
>> On Tue, 13 Aug 2019 at 03:35, Kever Yang <kever.yang@rock-chips.com> 
>> wrote:
>>>
>>> Hi Simon,
>>>
>>>      I got fail in test/py sandbox_spl, and the log says:
>>>
>>> E OSError: [Errno 5] Input/output error
>>>
>>> I have no idea about what's wrong in source code, could you help
>>>
>>> to take a look?
>>>
>>> Travis job:
>>>
>>> https://travis-ci.org/keveryang/u-boot/jobs/571125119
>>
>> When I've seen this (ugly) error it is normally because U-Boot
>> crashed, e.g. with a segfault.
>
> Yes, that's the typical reason. If you run test.py locally you'll be 
> able to access the log file (which Travis doesn't save), which will 
> likely give you more details about the crash, and/or you could attach 
> gdb to the sandbox process to trap the problem too.

I got:

$ ./u-boot
bloblist_init() Existing bloblist not found: creating new bloblist
[1]    958 segmentation fault (core dumped)  ./u-boot

And no more logs, is there any other log file I can check?


Thanks,

- Kever

[U-Boot] Travis test/py sandbox_spl test fail

[Stephen Warren]

On 8/13/19 8:06 PM, Kever Yang wrote:
> Hi Stephen,
> 
> On 2019/8/14 上午4:54, Stephen Warren wrote:
>> On 8/13/19 3:39 AM, Simon Glass wrote:
>>> +Stephen
>>>
>>> Hi Kever,
>>>
>>> On Tue, 13 Aug 2019 at 03:35, Kever Yang <kever.yang@rock-chips.com> 
>>> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>>      I got fail in test/py sandbox_spl, and the log says:
>>>>
>>>> E OSError: [Errno 5] Input/output error
>>>>
>>>> I have no idea about what's wrong in source code, could you help
>>>>
>>>> to take a look?
>>>>
>>>> Travis job:
>>>>
>>>> https://travis-ci.org/keveryang/u-boot/jobs/571125119
>>>
>>> When I've seen this (ugly) error it is normally because U-Boot
>>> crashed, e.g. with a segfault.
>>
>> Yes, that's the typical reason. If you run test.py locally you'll be 
>> able to access the log file (which Travis doesn't save), which will 
>> likely give you more details about the crash, and/or you could attach 
>> gdb to the sandbox process to trap the problem too.
> 
> I got:
> 
> $ ./u-boot
> bloblist_init() Existing bloblist not found: creating new bloblist
> [1]    958 segmentation fault (core dumped)  ./u-boot
> 
> And no more logs, is there any other log file I can check?

There probably isn't any more log information beyond that. I think the 
next step would be to run U-Boot sandbox under gdb, reproduce the 
problem, and then debug it.

[U-Boot] Travis test/py sandbox_spl test fail

[Kever Yang]

Hi Simon, Stephen,

     Could you help to comment on my other mail, which patch cause this 
failure.


Thanks,

- Kever

On 2019/8/14 下午11:49, Stephen Warren wrote:
> On 8/13/19 8:06 PM, Kever Yang wrote:
>> Hi Stephen,
>>
>> On 2019/8/14 上午4:54, Stephen Warren wrote:
>>> On 8/13/19 3:39 AM, Simon Glass wrote:
>>>> +Stephen
>>>>
>>>> Hi Kever,
>>>>
>>>> On Tue, 13 Aug 2019 at 03:35, Kever Yang 
>>>> <kever.yang@rock-chips.com> wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>>      I got fail in test/py sandbox_spl, and the log says:
>>>>>
>>>>> E OSError: [Errno 5] Input/output error
>>>>>
>>>>> I have no idea about what's wrong in source code, could you help
>>>>>
>>>>> to take a look?
>>>>>
>>>>> Travis job:
>>>>>
>>>>> https://travis-ci.org/keveryang/u-boot/jobs/571125119
>>>>
>>>> When I've seen this (ugly) error it is normally because U-Boot
>>>> crashed, e.g. with a segfault.
>>>
>>> Yes, that's the typical reason. If you run test.py locally you'll be 
>>> able to access the log file (which Travis doesn't save), which will 
>>> likely give you more details about the crash, and/or you could 
>>> attach gdb to the sandbox process to trap the problem too.
>>
>> I got:
>>
>> $ ./u-boot
>> bloblist_init() Existing bloblist not found: creating new bloblist
>> [1]    958 segmentation fault (core dumped)  ./u-boot
>>
>> And no more logs, is there any other log file I can check?
>
> There probably isn't any more log information beyond that. I think the 
> next step would be to run U-Boot sandbox under gdb, reproduce the 
> problem, and then debug it.

[U-Boot] Travis test/py sandbox_spl test fail

[Stephen Warren]

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.

> 
> 
> Thanks,
> 
> - Kever
> 
> On 2019/8/14 下午11:49, Stephen Warren wrote:
>> On 8/13/19 8:06 PM, Kever Yang wrote:
>>> Hi Stephen,
>>>
>>> On 2019/8/14 上午4:54, Stephen Warren wrote:
>>>> On 8/13/19 3:39 AM, Simon Glass wrote:
>>>>> +Stephen
>>>>>
>>>>> Hi Kever,
>>>>>
>>>>> On Tue, 13 Aug 2019 at 03:35, Kever Yang 
>>>>> <kever.yang@rock-chips.com> wrote:
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>>      I got fail in test/py sandbox_spl, and the log says:
>>>>>>
>>>>>> E OSError: [Errno 5] Input/output error
>>>>>>
>>>>>> I have no idea about what's wrong in source code, could you help
>>>>>>
>>>>>> to take a look?
>>>>>>
>>>>>> Travis job:
>>>>>>
>>>>>> https://travis-ci.org/keveryang/u-boot/jobs/571125119
>>>>>
>>>>> When I've seen this (ugly) error it is normally because U-Boot
>>>>> crashed, e.g. with a segfault.
>>>>
>>>> Yes, that's the typical reason. If you run test.py locally you'll be 
>>>> able to access the log file (which Travis doesn't save), which will 
>>>> likely give you more details about the crash, and/or you could 
>>>> attach gdb to the sandbox process to trap the problem too.
>>>
>>> I got:
>>>
>>> $ ./u-boot
>>> bloblist_init() Existing bloblist not found: creating new bloblist
>>> [1]    958 segmentation fault (core dumped)  ./u-boot
>>>
>>> And no more logs, is there any other log file I can check?
>>
>> There probably isn't any more log information beyond that. I think the 
>> next step would be to run U-Boot sandbox under gdb, reproduce the 
>> problem, and then debug it.
> 
> 

[U-Boot] Travis test/py sandbox_spl test fail

[Kever Yang]

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/

Thanks,

- Kever

>
>>
>>
>> Thanks,
>>
>> - Kever
>>
>> On 2019/8/14 下午11:49, Stephen Warren wrote:
>>> On 8/13/19 8:06 PM, Kever Yang wrote:
>>>> Hi Stephen,
>>>>
>>>> On 2019/8/14 上午4:54, Stephen Warren wrote:
>>>>> On 8/13/19 3:39 AM, Simon Glass wrote:
>>>>>> +Stephen
>>>>>>
>>>>>> Hi Kever,
>>>>>>
>>>>>> On Tue, 13 Aug 2019 at 03:35, Kever Yang 
>>>>>> <kever.yang@rock-chips.com> wrote:
>>>>>>>
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>>      I got fail in test/py sandbox_spl, and the log says:
>>>>>>>
>>>>>>> E OSError: [Errno 5] Input/output error
>>>>>>>
>>>>>>> I have no idea about what's wrong in source code, could you help
>>>>>>>
>>>>>>> to take a look?
>>>>>>>
>>>>>>> Travis job:
>>>>>>>
>>>>>>> https://travis-ci.org/keveryang/u-boot/jobs/571125119
>>>>>>
>>>>>> When I've seen this (ugly) error it is normally because U-Boot
>>>>>> crashed, e.g. with a segfault.
>>>>>
>>>>> Yes, that's the typical reason. If you run test.py locally you'll 
>>>>> be able to access the log file (which Travis doesn't save), which 
>>>>> will likely give you more details about the crash, and/or you 
>>>>> could attach gdb to the sandbox process to trap the problem too.
>>>>
>>>> I got:
>>>>
>>>> $ ./u-boot
>>>> bloblist_init() Existing bloblist not found: creating new bloblist
>>>> [1]    958 segmentation fault (core dumped)  ./u-boot
>>>>
>>>> And no more logs, is there any other log file I can check?
>>>
>>> There probably isn't any more log information beyond that. I think 
>>> the next step would be to run U-Boot sandbox under gdb, reproduce 
>>> the problem, and then debug it.
>>
>>
>
>

[U-Boot] Travis test/py sandbox_spl test fail

[Simon Glass]

Hi Kever,

On Mon, 19 Aug 2019 at 19:53, Kever Yang <kever.yang@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@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?

(gdb) where
#0  0x0000555555617db5 in strcmp (cs=cs at entry=0x5555556602cf "root_driver",
    ct=0x1 <error: Cannot access memory@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

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

[Kever Yang]

On 2019/8/24 下午12:19, Simon Glass wrote:
> Hi Kever,
>
> On Mon, 19 Aug 2019 at 19:53, Kever Yang <kever.yang@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@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
>
> (gdb) where
> #0  0x0000555555617db5 in strcmp (cs=cs at entry=0x5555556602cf "root_driver",
>      ct=0x1 <error: Cannot access memory@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
>

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

[Simon Glass]

Hi Kever,

On Thu, 29 Aug 2019 at 02:27, Kever Yang <kever.yang@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@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@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@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
>