[OE-core] gdb failure on simplest hello world program -- oe-selftest

[ChenQi]

Hi All,

I've filed a bug for this issue.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13123

I could spend time to work on it, but I really don't know how to start.
Hope some experts could help or give me some advice.

Best Regards,
Chen Qi

On 12/29/2018 11:26 AM, ChenQi wrote:
> On 12/29/2018 01:09 AM, Khem Raj wrote:
>>
>>
>> On 12/28/18 8:31 AM, richard.purdie at linuxfoundation.org wrote:
>>> On Fri, 2018-12-28 at 17:49 +0800, ChenQi wrote:
>>>> On 12/26/2018 07:06 PM, richard.purdie at linuxfoundation.org wrote:
>>>>> On Wed, 2018-12-26 at 10:09 +0800, ChenQi wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> 'oe-selftest -r package.PackageTests.test_gdb_hardlink_debug'
>>>>>> fails.
>>>>>> I did the tests on both my Fedora27 and ubuntu16.04 servers. They
>>>>>> both
>>>>>> failed.
>>>>>> I can also reproduce this issue manually.
>>>>>>
>>>>>> I did some investigation. No clue how to fix this it. So I want
>>>>>> to seek
>>>>>> help from community.
>>>>>>
>>>>>> Below is some output from oe-selftest.
>>>>>> [snip]
>>>>>> 2018-12-26 09:27:58,440 - oe-selftest - INFO -
>>>>>> test_gdb_hardlink_debug
>>>>>> (package.PackageTests)
>>>>>> 2018-12-26 09:37:55,333 - oe-selftest - INFO - gdbtest
>>>>>> /usr/bin/hello1
>>>>>> 2018-12-26 09:37:59,904 - oe-selftest - ERROR - GDB result:
>>>>>> 1: Reading symbols from /usr/bin/hello1...Reading symbols from
>>>>>> /usr/bin/.debug/hello4...done.
>>>>>> done.
>>>>>> (gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h,
>>>>>> line 107.
>>>>>> (gdb) Starting program: /usr/bin/hello1
>>>>>>
>>>>>> Breakpoint 1, main () at /usr/include/bits/stdio2.h:107
>>>>>> 107    /usr/include/bits/stdio2.h: No such file or directory.
>>>>>> (gdb) Continuing.
>>>>>> Hello World!
>>>>>> [Inferior 1 (process 312) exited normally]
>>>>>> (gdb)
>>>>>> 2018-12-26 09:38:00,907 - oe-selftest - INFO -  ... FAIL
>>>>>> [snip]
>>>>>>
>>>>>> The hello world problem is as follows.
>>>>>> $ cat
>>>>>> meta-selftest/recipes-test/selftest-hardlink/selftest-
>>>>>> hardlink/hello.c
>>>>>> #include <stdio.h>
>>>>>>
>>>>>> int main() {
>>>>>>       printf("Hello World!\n");
>>>>>> }
>>>>>>
>>>>>> Some extra information:
>>>>>> 1. Remove '-O2' or '-D_FORTIFY_SOURCE=2', and it works correctly.
>>>>>> 2. Adding some system call like daemon(0,0) before printf also
>>>>>> works.
>>>>>> 3. Reverting poky repo to
>>>>>> 1c048479af7cc98e30f9a33d1f3bef03711544aa,
>>>>>> which adds this selftest case, does not work. It still fails.
>>>>>> 4. Hongxu confirms that things work on his host.
>>>>>> 5. I also don't see failure about this test case on yocto's
>>>>>> autobuilder.
>>>>>>
>>>>>> Could somebody help to provide some suggestions?
>>>>>
>>>>> This is strange and there must be some difference between your
>>>>> configuration and what what we test on the autobuilder or on
>>>>> Hongxu's
>>>>> setup.
>>>>   Hi Richard,
>>>>
>>>> I have talked with Hongxu and we can now both confirm that there does
>>>> exist some problem.
>>>>
>>>>> Which DISTRO and MACHINE are you using?
>>>>   DISTRO is poky
>>>> MACHINE is qemux86.
>>>>
>>>> It seems that if MACHINE is qemux86-64, the test case could pass. But
>>>> that's just because the test case only checks 'Breakpoint 1, main ()
>>>> at hello.c:4'. See the console output below.
>>>> (gdb) b main
>>>> Breakpoint 1 at 0x1050: file /usr/include/bits/stdio2.h, line 107.
>>>> (gdb) r
>>>> Starting program: /usr/bin/hello1
>>>>
>>>> Breakpoint 1, main () at hello.c:4
>>>> 4        printf("Hello World!\n");
>>>> (gdb) c
>>>> Continuing.
>>>> Hello World!
>>>> [Inferior 1 (process 156) exited normally]
>>>> (gdb) q
>>>>
>>>> Even in this case, the 'b main' does not give correct result. The
>>>> test case passes because 'Breakpoint 1, main () at hello.c:4' is
>>>> there.
>>>>
>>>> On qemux86, we have:
>>>> (gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line
>>>> 107.
>>>> (gdb) Starting program: /usr/bin/hello1
>>>>
>>>> Breakpoint 1, main () at /usr/include/bits/stdio2.h:107
>>>> 107    /usr/include/bits/stdio2.h: No such file or directory.
>>>> (gdb) Continuing.
>>>> Hello World!
>>>> [Inferior 1 (process 156) exited normally]
>>>> (gdb)
>>>>
>>>>> I think the key to resolving this is will be to understanding how
>>>>> to
>>>>> reproduce it...
>>>>   Two ways to reproduce the problem:
>>>>
>>>> I) reproduce it via oe-selftest
>>>> 1) . oe-init-build-env build-selftest
>>>> 2) SANITY_TESTED_DISTROS = ""
>>>> 3) oe-selftest -r package.PackageTests.test_gdb_hardlink_debug
>>>>
>>>> II) reproduce it manually
>>>> 1) add meta-selftest to bblayers.conf
>>>> 2) IMAGE_INSTALL_append = " selftest-hardlink selftest-hardlink-dbg
>>>> selftest-hardlink-gdb"
>>>> 3) bitbake core-image-minimal
>>>> 4) On target:
>>>>       gdb /usr/bin/hello1
>>>>       (gdb) b main
>>>
>>> I confirmed I could also reproduce it. We've just been lucky with the
>>> configuration the autobuilder tests.
>>>
>>> I think we need to improve the test case. Does installing the libc
>>> headers/dev package so that stdio2.h is there help?
>>
>> This is not exported API so libc headers may not work but installing 
>> libc dev package should help here.
>>
>
> Hi Richard and Khem,
>
> Unfortunately installing libc-dev package does not help.
>
> On qemux86:
> 1: Reading symbols from /usr/bin/hello1...Reading symbols from 
> /usr/bin/.debug/hello4...done.
> done.
> *(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line 107.*
> (gdb) Starting program: /usr/bin/hello1
>
> *Breakpoint 1, main () at /usr/include/bits/stdio2.h:107**
> **107      return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, 
> __va_arg_pack ());*
> (gdb) Continuing.
> Hello World!
> [Inferior 1 (process 309) exited normally]
> (gdb)
> 2018-12-29 10:58:11,538 - oe-selftest - INFO -  ... FAIL
>
> For qemux86-64, things are the same.
>
> Best Regards,
> Chen Qi
>
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190107/007dcc28/attachment-0001.html>