Re: [yocto] [meta-raspberrypi] Is Preempt-rt still supported in master / latest releases?
Hi Carles > Hi Alex, Andrei, > > thanks for your reply. Based on your feedback I've tried the > following: > - I have downloaded the patch patch-5.15.86-rt56.patch from > https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.15/ and stored > in ./meta-raspberrypi/recipes-kernel/linux/files > - I have created a file linux-raspberrypi_%.bbappend in > ./meta-raspberrypi/recipes-kernel/linux > - I have created a .cfg file with CONFIG_PREEMPT_RT_FULL = y in > ./meta-raspberrypi/recipes-kernel/linux/files > - I have added both patch and cfg file in bbappend using > SRC_URI:append:rpi. > > I can observe the following: > - patch and cfg files are available in > ./build/tmp/work/raspberrypi4_64-agl-linux/linux-raspberrypi/1_5.15.34+gitAUTOINC+e1b976ee4f_0086da6acd-r0 > - new folder linux-raspberrypi4_64-preempt-rt-build is available > inside the folder above. But the problem seems to be that > CONFIG_PREEMPT_RT = y is not applied to the .config file. So it seems > the preempt-rt kernel is built but without the full preempt-rt > support. > - When I do bitbake linux-raspberrypi -c menuconfig I cannot select > the full real time preempt kernel, only preemptible option available > is --> Preemptible Kernel (Low-Latency Desktop). Fully Preemptible > Kernel (Real-Time) is not available. > - When I flash the image in the Rpi4 and run uname -r I see that the > rt kernel has been built --> 5.15.34.rt56.v8 > - but only with PREEMPT option but without RT when I do uname -v --> > #1 SMP PREEMPT Tue Aug 9 21:20:00 UTC 2022 (without RT). > > I have tried building linux-yocto-rt for qemu and there I see that > CONFIG_PREEMP_RT = y is available in the .config file. Also if I open > menuconfig I have the option to select in General setup --> > Preemption Model --> Fully Preemptible Kernel (Real-Time) > > If you can provide any hints on what am I missing it would be highly > appreciated. > Have you managed to go any further with your investigation regarding PREEMPT-RT on RPi4-64? > Best Regards, > Carles Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpmyDHDubJT_.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#59105): https://lists.yoctoproject.org/g/yocto/message/59105 Mute This Topic: https://lists.yoctoproject.org/mt/96470693/21656 Mute #raspberrypi:https://lists.yoctoproject.org/g/yocto/mutehashtag/raspberrypi Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
Hi Alexander, > On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote: > > 2. There are ptest available [2] to validate if the Y2038 problem > > works correctly. > > > > 3. Support for running ptests mentioned in point 2. is already > > available in the poky repository [3]. > > I just ran these tests in (32 bit) qemux86 on top of poky master (e.g. > no magic glibc flags), and they all passed. Do they need to be ran > after setting the date to the 'post-2038 future' to reveal the issues > and produce failures? Yes. You need to run them with adjusted date: date +'%Y-%m-%d %T' -s "2038-01-19 03:14:07" ptest-runner glibc-tests More info: https://github.com/lmajewski/meta-y2038/blob/master/README#L201 > > Alex Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpZZ7nYE2u3S.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58693): https://lists.yoctoproject.org/g/yocto/message/58693 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
Hi Richard, > On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > wrote: > > > We’d welcome a proposal/series on how to move forward with the > > > Y2038 work for 32 bit platforms. > > > > I have the following proposal: > > > > 1. A branch is made where: > > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > > b. qemu is always started with "-rtc base=2040-01-01", simulating > > Y2038 actually occurring. > > c. an additional runtime test verifies that both RTC clock and > > system clock report 2040. > > > > 2. This branch is run through a-full on the autobuilder. Any > > uncovered issues are filed as bugs. > > > > 3. Once *all* of the bugs are addressed, repeat point 2. > > > > 4. Once there are no more open bugs, 1a is merged into master. > > > > Any fatal flaws in the plan? > > Others have made some good comments. My thoughts: > > * We need to add some runtime tests to oeqa for this (in addition to > the ptests) > > * We need to have a 32 bit ptest run on the autobuilder (qemux86 > should work, not sure we can make qemuarm fast). Whether this is > manually triggered, not sure. We could have a smaller set of ptests > to run for it? Y2038 ptests maybe? Here is the list of integrated tests to ptests: https://github.com/lmajewski/y2038-tests > > * Could we optionally disable some of the glibc 32 bit function calls > to ensure they're not being used? Could you be more specific here? Would you like to disable some syscalls? > We don't really want to diverge from > upstream glibc much though. Could you be more specific here? The glibc now supports the whole set of syscalls as of 2.34 version? To enable them one needs to pass -D_TIME_BITS=64 flag when compiling programs. This is now the official glibc ABI. > > * We need to work out how to communicate this change happened and have > people "buy in" to it. Ok. > The reason for that is that if someone has > existing binaries, there could be problems using them after the > change. The binary shall work without issues on glibc 2.34+ and 5.10+ kernel without issues. The only problem happens when new binaries with 64 bit time support are run on glibc or kernel not supporting 64 bit time. > We therefore need to be sure they are aware of it. > > Cheers, > > Richard > > > > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpFXqfNXSdfb.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58678): https://lists.yoctoproject.org/g/yocto/message/58678 Mute This Topic: https://lists.yoctoproject.org/mt/95357621/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [yocto] Y2038 proposal
On Wed, 30 Nov 2022 13:07:27 +0100 "Alexander Kanavin" wrote: > On Wed, 30 Nov 2022 at 12:40, Richard Purdie > wrote: > > > To be clear, we don't run ptests on 32 bit targets, only on > > qemux86-64 and qemuarm64 where we have KVM available. We do run > > image, sdk and eSDK tests on our supported qemu targets, 32 and 64 > > bit. > > I think kvm does allow 32 bit guest on a 64 bit host. +1 IIRC the MACH=qemux86 was working correctly... > But I can > imagine making full ptests work on 32 bit guests Maybe only subset of ptests - i.e. those related to Y2038 could be run? > would be a struggle > for reasons unrelated to 2038, specifically lack of users outside of > embedded world. > > Alex Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpWOBF1a_wZb.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58674): https://lists.yoctoproject.org/g/yocto/message/58674 Mute This Topic: https://lists.yoctoproject.org/mt/95355888/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
On Wed, 30 Nov 2022 05:52:03 -0500 "Stephen John Smoogen" wrote: > On Wed, 30 Nov 2022 at 03:08, Alexander Kanavin > wrote: > > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > wrote: > > > We’d welcome a proposal/series on how to move forward with the > > > Y2038 > > work for 32 bit platforms. > > > > I have the following proposal: > > > > 1. A branch is made where: > > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > > b. qemu is always started with "-rtc base=2040-01-01", simulating > > Y2038 actually occurring. > > c. an additional runtime test verifies that both RTC clock and > > system clock report 2040. > > > > > Going from various problems I saw with systems with smaller time > wraps, setting a time after wrap occurs misses most of the problems > which wall occur. Many systems will work fine with either 'negative' > or 'smaller dates' but crash, burn, etc when running when the counter > wraps around. I would suggest setting the test date to -N minutes > before wrap over to run a first set of tests, and then N minutes > after the wrap to run a second set of tests. This would hopefully > catch programs which are worse off. > IIRC ptests for y2038 covers this problem in this exact way. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpl0cjdjjqBQ.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58670): https://lists.yoctoproject.org/g/yocto/message/58670 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
Hi Alexander, > On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote: > > Please find a few comments: > > > > 1. There is already provided meta-y2038 [1] to test if 32 bit > > systems correctly support Y2038 problem. It uses qemu machines from > > OE/Yocto > > > > 2. There are ptest available [2] to validate if the Y2038 problem > > works correctly. > > > > 3. Support for running ptests mentioned in point 2. is already > > available in the poky repository [3]. > > Thanks! So there should be a > > d. 'glibc-tests-ptest' is executed across all architectures - probably > as a machine-specific selftest, and as well with qemu time set into > the future. +1 > > > It looks like the meta-y2038 can be used out of the box (after > > checking if it still works with newest poky) when added to the > > Yocto Project build/test infrastructure. > > Unfortunately I do not think that layer can be easily added into the > test matrix. It has its own distro and images. No, we need to maintain > a poky branch where the same tweaks and fixes happen. Besides, those > fixes would need to be merged into oe-core proper eventually anyway. > It would be even better if the meta-y2038 could be dropped and _all_ its functionality could be merged to poky. That would be _awesome_. Please just be aware that this meta layer has some fixes for some packages (for Y2038 ready glibc). > Alex Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpQ80_v7k1d3.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58666): https://lists.yoctoproject.org/g/yocto/message/58666 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
Hi Alexander, > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > wrote: > > We’d welcome a proposal/series on how to move forward with the > > Y2038 work for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > b. qemu is always started with "-rtc base=2040-01-01", simulating > Y2038 actually occurring. > c. an additional runtime test verifies that both RTC clock and system > clock report 2040. > Please find a few comments: 1. There is already provided meta-y2038 [1] to test if 32 bit systems correctly support Y2038 problem. It uses qemu machines from OE/Yocto 2. There are ptest available [2] to validate if the Y2038 problem works correctly. 3. Support for running ptests mentioned in point 2. is already available in the poky repository [3]. > 2. This branch is run through a-full on the autobuilder. Any uncovered > issues are filed as bugs. > > 3. Once *all* of the bugs are addressed, repeat point 2. > > 4. Once there are no more open bugs, 1a is merged into master. > > Any fatal flaws in the plan? > > It's not hard to see that Y2038 problem is real and serious, e.g. on > qemux86 core-image-full-cmdline built from master: > > root@qemux86:~# ls / > bin boot devetc home liblost+found media mntproc > run sbin sys tmp usrvar > root@qemux86:~# date -s "2040-01-01" > Sun Jan 1 00:00:00 UTC 2040 > root@qemux86:~# ls / > bin boot devetc home liblost+found media mntproc > run sbin sys tmp usrvar > root@qemux86:~# ls / > -sh: ls: command not found > > On qemux86_64 the same sequence works as expected, of course. > Yes, y2038 is an important issue. I would be more than happy if we could reuse the previous work [1]. I've used OE/Yocto to validate the code during developing support for '-D_TIME_BITS=64 ' flag in glibc. It looks like the meta-y2038 can be used out of the box (after checking if it still works with newest poky) when added to the Yocto Project build/test infrastructure. > Alex Links: [1] - https://github.com/lmajewski/meta-y2038 [2] - https://github.com/lmajewski/meta-y2038/blob/master/README#L201 [3] - https://git.yoctoproject.org/poky/commit/?id=0e0c481a25f10f8f7ff1d69bda7f015186da0202 Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpTgIKasUGYm.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58664): https://lists.yoctoproject.org/g/yocto/message/58664 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH v2 ptest-runner 2/2] main: Do not return number of failed tests when calling ptest-runner
Hi Alexander, > I think we might be having an 'unresponsive maintainer' situation? > How can Anibal be reached? I saw recenlty your patches on this topic. Is there a chance that Anibal will pull/review them soon? It looks like those are crucial for ptest-runner operation. > > Alex > > On Mon, 20 Sept 2021 at 11:19, ?ukasz Majewski wrote: > > > Hi Anibal, > > > > > Hi Anibal, > > > > > > > Up till now ptest-runner2 returns number of failed tests with > > > > its exit status code. Such use case is not recommended [1] and > > > > may cause issues when there are more than 256 tests to be > > > > executed. > > > > > > > > To alleviate this issue the number of total tests with number of > > > > failed ones is printed before exit. To be more specific - > > > > failure of tests (one or more) causes ptest-runner to provide > > > > exit code of 1. > > > > > > > > One can test this change with executing: > > > > ./ptest-runner -d tests/data fail > > > > > > Gentle ping on this patch. > > > > > > > Gentle ping on this patch. > > > > Is it OK to be applied? > > > > > > > > > > Links: > > > > [1] - > > > > https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html > > > > > > > > Signed-off-by: Lukasz Majewski > > > > --- > > > > Changes for v2: > > > > - When number of failed tests is N, the ptest-runner returns > > > > value of 1 to indicate error in the execution > > > > --- > > > > main.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/main.c b/main.c > > > > index 890bc6a..bcec844 100644 > > > > --- a/main.c > > > > +++ b/main.c > > > > @@ -220,6 +220,9 @@ main(int argc, char *argv[]) > > > > ptest_list_remove(run, opts.exclude[i], 1); > > > > > > > > rc = run_ptests(run, opts, argv[0], stdout, stderr); > > > > + fprintf(stdout, "TOTAL: %d FAIL: %d\n", > > > > ptest_list_length(run), rc); > > > > + if (rc > 0) > > > > + rc = 1; > > > > > > > > ptest_list_free_all(); > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > Lukasz Majewski > > > > > > -- > > > > > > DENX Software Engineering GmbH, Managing Director: Wolfgang > > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 > > > Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: > > > (+49)-8142-66989-80 Email: lu...@denx.de > > > > > > > > > > Best regards, > > > > Lukasz Majewski > > > > -- > > > > DENX Software Engineering GmbH, Managing Director: Wolfgang > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: > > lu...@denx.de > > > > > > > > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpZQ2iSSa8bC.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54872): https://lists.yoctoproject.org/g/yocto/message/54872 Mute This Topic: https://lists.yoctoproject.org/mt/84946492/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH v2 ptest-runner 2/2] main: Do not return number of failed tests when calling ptest-runner
Hi Anibal, > Hi Anibal, > > > Up till now ptest-runner2 returns number of failed tests with its > > exit status code. Such use case is not recommended [1] and may cause > > issues when there are more than 256 tests to be executed. > > > > To alleviate this issue the number of total tests with number of > > failed ones is printed before exit. To be more specific - failure of > > tests (one or more) causes ptest-runner to provide exit code of 1. > > > > One can test this change with executing: > > ./ptest-runner -d tests/data fail > > Gentle ping on this patch. > Gentle ping on this patch. Is it OK to be applied? > > > > Links: > > [1] - > > https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html > > > > Signed-off-by: Lukasz Majewski > > --- > > Changes for v2: > > - When number of failed tests is N, the ptest-runner returns value > > of 1 to indicate error in the execution > > --- > > main.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/main.c b/main.c > > index 890bc6a..bcec844 100644 > > --- a/main.c > > +++ b/main.c > > @@ -220,6 +220,9 @@ main(int argc, char *argv[]) > > ptest_list_remove(run, opts.exclude[i], 1); > > > > rc = run_ptests(run, opts, argv[0], stdout, stderr); > > + fprintf(stdout, "TOTAL: %d FAIL: %d\n", > > ptest_list_length(run), rc); > > + if (rc > 0) > > + rc = 1; > > > > ptest_list_free_all(); > > > > > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: > lu...@denx.de Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpCDv9dmg7p4.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54769): https://lists.yoctoproject.org/g/yocto/message/54769 Mute This Topic: https://lists.yoctoproject.org/mt/84946492/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH v2 ptest-runner 2/2] main: Do not return number of failed tests when calling ptest-runner
Hi Anibal, > Up till now ptest-runner2 returns number of failed tests with its > exit status code. Such use case is not recommended [1] and may cause > issues when there are more than 256 tests to be executed. > > To alleviate this issue the number of total tests with number of > failed ones is printed before exit. To be more specific - failure of > tests (one or more) causes ptest-runner to provide exit code of 1. > > One can test this change with executing: > ./ptest-runner -d tests/data fail Gentle ping on this patch. > > Links: > [1] - > https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html > > Signed-off-by: Lukasz Majewski > --- > Changes for v2: > - When number of failed tests is N, the ptest-runner returns value of > 1 to indicate error in the execution > --- > main.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/main.c b/main.c > index 890bc6a..bcec844 100644 > --- a/main.c > +++ b/main.c > @@ -220,6 +220,9 @@ main(int argc, char *argv[]) > ptest_list_remove(run, opts.exclude[i], 1); > > rc = run_ptests(run, opts, argv[0], stdout, stderr); > + fprintf(stdout, "TOTAL: %d FAIL: %d\n", > ptest_list_length(run), rc); > + if (rc > 0) > + rc = 1; > > ptest_list_free_all(); > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpw23ZeQ5Yn1.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54579): https://lists.yoctoproject.org/g/yocto/message/54579 Mute This Topic: https://lists.yoctoproject.org/mt/84946492/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH v2 ptest-runner 2/2] main: Do not return number of failed tests when calling ptest-runner
Up till now ptest-runner2 returns number of failed tests with its exit status code. Such use case is not recommended [1] and may cause issues when there are more than 256 tests to be executed. To alleviate this issue the number of total tests with number of failed ones is printed before exit. To be more specific - failure of tests (one or more) causes ptest-runner to provide exit code of 1. One can test this change with executing: ./ptest-runner -d tests/data fail Links: [1] - https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html Signed-off-by: Lukasz Majewski --- Changes for v2: - When number of failed tests is N, the ptest-runner returns value of 1 to indicate error in the execution --- main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/main.c b/main.c index 890bc6a..bcec844 100644 --- a/main.c +++ b/main.c @@ -220,6 +220,9 @@ main(int argc, char *argv[]) ptest_list_remove(run, opts.exclude[i], 1); rc = run_ptests(run, opts, argv[0], stdout, stderr); + fprintf(stdout, "TOTAL: %d FAIL: %d\n", ptest_list_length(run), rc); + if (rc > 0) + rc = 1; ptest_list_free_all(); -- 2.20.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54434): https://lists.yoctoproject.org/g/yocto/message/54434 Mute This Topic: https://lists.yoctoproject.org/mt/84946492/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH v2 ptest-runner 1/2] mem: Refactor ptest_list cleanup
From: Adrian Freihofer
Try to make memory management more robust by assigning always NULL to
struct ptest_list pointers. It's a refactoring which probably improves
the code but does not fix a concrete bug.
Signed-off-by: Adrian Freihofer
---
Changes for v2 [lukma]:
- Rebase from origin/dev to origin/master (the dev branch had
some adjustments for timeout, which shall be discarded as not
needed anymore.
---
main.c | 9 +
ptest_list.c | 13 -
ptest_list.h | 8 +---
tests/ptest_list.c | 13 +++--
tests/utils.c | 22 +++---
utils.c| 6 +++---
6 files changed, 31 insertions(+), 40 deletions(-)
diff --git a/main.c b/main.c
index 2b13ef5..890bc6a 100644
--- a/main.c
+++ b/main.c
@@ -117,7 +117,8 @@ main(int argc, char *argv[])
mtrace();
#endif
- struct ptest_list *head, *run;
+ struct ptest_list *head = NULL;
+ struct ptest_list *run = NULL;
__attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options
opts;
opts.dirs = malloc(sizeof(char **) * 1);
@@ -176,7 +177,7 @@ main(int argc, char *argv[])
head = NULL;
for (i = 0; i < opts.dirs_no; i ++) {
- struct ptest_list *tmp;
+ struct ptest_list *tmp = NULL;
tmp = get_available_ptests(opts.dirs[i]);
if (tmp == NULL) {
@@ -212,7 +213,7 @@ main(int argc, char *argv[])
run = filter_ptests(head, opts.ptests, ptest_num);
CHECK_ALLOCATION(run, (size_t) ptest_num, 1);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
for (i = 0; i < ptest_exclude_num; i++)
@@ -220,7 +221,7 @@ main(int argc, char *argv[])
rc = run_ptests(run, opts, argv[0], stdout, stderr);
- ptest_list_free_all(run);
+ ptest_list_free_all();
return rc;
}
diff --git a/ptest_list.c b/ptest_list.c
index 917ef4f..0c0e5b2 100644
--- a/ptest_list.c
+++ b/ptest_list.c
@@ -69,24 +69,19 @@ ptest_list_free(struct ptest_list *p)
free(p);
}
-int
-ptest_list_free_all(struct ptest_list *head)
+void
+ptest_list_free_all(struct ptest_list **head)
{
- int i = 0;
struct ptest_list *p, *q;
- VALIDATE_PTR_RINT(head);
-
- p = head;
+ p = *head;
while (p != NULL) {
q = p;
p = p->next;
ptest_list_free(q);
- i++;
}
-
- return i;
+ *head = NULL;
}
int
diff --git a/ptest_list.h b/ptest_list.h
index 02a64bb..658a07a 100644
--- a/ptest_list.h
+++ b/ptest_list.h
@@ -36,12 +36,6 @@
x = NULL; \
} while (0)
-#define PTEST_LIST_FREE_ALL_CLEAN(x) \
- do { \
- ptest_list_free_all(x); \
- x = NULL; \
- } while (0)
-
#define PTEST_LIST_ITERATE_START(head, p) for (p = head->next; p != NULL; p =
p->next) {
#define PTEST_LIST_ITERATE_END }
@@ -57,7 +51,7 @@ struct ptest_list {
extern struct ptest_list *ptest_list_alloc(void);
extern void ptest_list_free(struct ptest_list *);
-extern int ptest_list_free_all(struct ptest_list *);
+extern void ptest_list_free_all(struct ptest_list **);
extern int ptest_list_length(struct ptest_list *);
extern struct ptest_list *ptest_list_search(struct ptest_list *, char *);
diff --git a/tests/ptest_list.c b/tests/ptest_list.c
index 081f027..fc15acb 100644
--- a/tests/ptest_list.c
+++ b/tests/ptest_list.c
@@ -53,7 +53,7 @@ START_TEST(test_add)
{
struct ptest_list *head = ptest_list_alloc();
ck_assert(ptest_list_add(head, strdup("perl"), NULL) != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
END_TEST
@@ -62,14 +62,15 @@ START_TEST(test_free_all)
struct ptest_list *head = NULL;
int i;
- ck_assert(ptest_list_free_all(head) == -1);
+ ptest_list_free_all();
+ ck_assert(head == NULL);
ck_assert(errno == EINVAL);
head = ptest_list_alloc();
for (i = 0; i < ptests_num; i++)
ptest_list_add(head, strdup(ptest_names[i]), NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
END_TEST
@@ -87,7 +88,7 @@ START_TEST(test_length)
ptest_list_add(head, strdup(ptest_names[i]), NULL);
ck_assert_int_eq(ptest_list_length(head), ptests_num);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
END_TEST
@@ -109,7 +110,7 @@ START_TEST(test_search)
for (i = ptests_num - 1; i >= 0; i--)
ck_assert(ptest_list_search(head, ptest_names[i]) != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
END_TEST
@@ -141,7 +142,7 @@ START_TEST(test_remove)
ck_assert_int_eq(ptest_list_length(head), n);
ck_assert(ptest_list_search(head, "busybox") != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all();
Re: [yocto] [ptest-runner 0/5] ptest: Various memory fixes and enhancements
Hi Randy, > On 2021-07-21 5:46 a.m., ?ukasz Majewski wrote: > > This patch series provides some memory management fixes and > > corrected return code handling for ptest-runner2. > > > > Adrian Freihofer (4): > >git: Extend the gitignore > >mem: Fix memleak for ptest_opts > >mem: Simplify memory management > >mem: Refactor ptest_list cleanup > > > > Lukasz Majewski (1): > >main: Do not return number of failed tests when calling > > ptest-runner > > > > .gitignore | 3 +++ > > main.c | 33 - > > ptest_list.c | 13 - > > ptest_list.h | 8 +--- > > tests/ptest_list.c | 13 +++-- > > tests/utils.c | 22 +++--- > > utils.c| 11 --- > > 7 files changed, 58 insertions(+), 45 deletions(-) > > create mode 100644 .gitignore > > > > > > > > > > > > Looks good to me. > > Did you happen to check the compile with clang as well? > If not, I may do that eventually. > No, I've just used gcc. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpLyPu0bV0nQ.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54189): https://lists.yoctoproject.org/g/yocto/message/54189 Mute This Topic: https://lists.yoctoproject.org/mt/84352905/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [ptest-runner 5/5] main: Do not return number of failed tests when calling ptest-runner
Up till now ptest-runner2 returns number of failed tests with its exit status code. Such use case is not recommended [1] and may cause issues when there are more than 256 tests to be executed. To alleviate this issue the number of total tests with number of failed ones is printed before exit. To be more specific - failure of a single test doesn't indicate that the ptest-runner itself encounter any issue during its execution. One can test this change with executing: ./ptest-runner -d tests/data fail Links: [1] - https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html Signed-off-by: Lukasz Majewski --- main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/main.c b/main.c index efa21b2..9f03857 100644 --- a/main.c +++ b/main.c @@ -219,6 +219,9 @@ main(int argc, char *argv[]) ptest_list_remove(run, opts.exclude[i], 1); rc = run_ptests(run, opts, argv[0], stdout, stderr); + fprintf(stdout, "TOTAL: %d FAIL: %d\n", ptest_list_length(run), rc); + if (rc > 0) + rc = 0; ptest_list_free_all(); -- 2.20.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54182): https://lists.yoctoproject.org/g/yocto/message/54182 Mute This Topic: https://lists.yoctoproject.org/mt/84352910/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [ptest-runner 4/5] mem: Refactor ptest_list cleanup
From: Adrian Freihofer
Try to make memory management more robust by assigning always NULL to
struct ptest_list pointers. It's a refactoring which probably improves
the code but does not fix a concrete bug.
Signed-off-by: Adrian Freihofer
---
main.c | 9 +
ptest_list.c | 13 -
ptest_list.h | 8 +---
tests/ptest_list.c | 13 +++--
tests/utils.c | 22 +++---
utils.c| 6 +++---
6 files changed, 31 insertions(+), 40 deletions(-)
diff --git a/main.c b/main.c
index e73626c..efa21b2 100644
--- a/main.c
+++ b/main.c
@@ -116,7 +116,8 @@ main(int argc, char *argv[])
mtrace();
#endif
- struct ptest_list *head, *run;
+ struct ptest_list *head = NULL;
+ struct ptest_list *run = NULL;
__attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options
opts;
opts.dirs = malloc(sizeof(char **) * 1);
@@ -175,7 +176,7 @@ main(int argc, char *argv[])
head = NULL;
for (i = 0; i < opts.dirs_no; i ++) {
- struct ptest_list *tmp;
+ struct ptest_list *tmp = NULL;
tmp = get_available_ptests(opts.dirs[i], opts.timeout);
if (tmp == NULL) {
@@ -211,7 +212,7 @@ main(int argc, char *argv[])
run = filter_ptests(head, opts.ptests, ptest_num);
CHECK_ALLOCATION(run, (size_t) ptest_num, 1);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
for (i = 0; i < ptest_exclude_num; i++)
@@ -219,7 +220,7 @@ main(int argc, char *argv[])
rc = run_ptests(run, opts, argv[0], stdout, stderr);
- ptest_list_free_all(run);
+ ptest_list_free_all();
return rc;
}
diff --git a/ptest_list.c b/ptest_list.c
index b689670..87b8c71 100644
--- a/ptest_list.c
+++ b/ptest_list.c
@@ -69,24 +69,19 @@ ptest_list_free(struct ptest_list *p)
free(p);
}
-int
-ptest_list_free_all(struct ptest_list *head)
+void
+ptest_list_free_all(struct ptest_list **head)
{
- int i = 0;
struct ptest_list *p, *q;
- VALIDATE_PTR_RINT(head);
-
- p = head;
+ p = *head;
while (p != NULL) {
q = p;
p = p->next;
ptest_list_free(q);
- i++;
}
-
- return i;
+ *head = NULL;
}
int
diff --git a/ptest_list.h b/ptest_list.h
index e583d9f..949250c 100644
--- a/ptest_list.h
+++ b/ptest_list.h
@@ -36,12 +36,6 @@
x = NULL; \
} while (0)
-#define PTEST_LIST_FREE_ALL_CLEAN(x) \
- do { \
- ptest_list_free_all(x); \
- x = NULL; \
- } while (0)
-
#define PTEST_LIST_ITERATE_START(head, p) for (p = head->next; p != NULL; p =
p->next) {
#define PTEST_LIST_ITERATE_END }
@@ -58,7 +52,7 @@ struct ptest_list {
extern struct ptest_list *ptest_list_alloc(void);
extern void ptest_list_free(struct ptest_list *);
-extern int ptest_list_free_all(struct ptest_list *);
+extern void ptest_list_free_all(struct ptest_list **);
extern int ptest_list_length(struct ptest_list *);
extern struct ptest_list *ptest_list_search(struct ptest_list *, char *);
diff --git a/tests/ptest_list.c b/tests/ptest_list.c
index 37d19ae..6bbc13b 100644
--- a/tests/ptest_list.c
+++ b/tests/ptest_list.c
@@ -53,7 +53,7 @@ START_TEST(test_add)
{
struct ptest_list *head = ptest_list_alloc();
ck_assert(ptest_list_add(head, strdup("perl"), NULL, 1) != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
END_TEST
@@ -62,14 +62,15 @@ START_TEST(test_free_all)
struct ptest_list *head = NULL;
int i;
- ck_assert(ptest_list_free_all(head) == -1);
+ ptest_list_free_all();
+ ck_assert(head == NULL);
ck_assert(errno == EINVAL);
head = ptest_list_alloc();
for (i = 0; i < ptests_num; i++)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
END_TEST
@@ -87,7 +88,7 @@ START_TEST(test_length)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);
ck_assert_int_eq(ptest_list_length(head), ptests_num);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
END_TEST
@@ -109,7 +110,7 @@ START_TEST(test_search)
for (i = ptests_num - 1; i >= 0; i--)
ck_assert(ptest_list_search(head, ptest_names[i]) != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
END_TEST
@@ -141,7 +142,7 @@ START_TEST(test_remove)
ck_assert_int_eq(ptest_list_length(head), n);
ck_assert(ptest_list_search(head, "busybox") != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all();
}
END_TEST
diff --git a/tests/utils.c b/tests/utils.c
index 8df1b54..4e244fe 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -88,13 +88,13 @@
[yocto] [ptest-runner 3/5] mem: Simplify memory management
From: Adrian Freihofer
Removes the following warnings thrown by
make && valgrind -s --leak-check=full ./ptest-runner -d tests/data2
==4154390== Invalid write of size 8
==4154390==at 0x40360D: run_child (utils.c:357)
==4154390==by 0x403C5B: run_ptests (utils.c:534)
==4154390==by 0x402C4D: main (main.c:223)
==4154390== Address 0x4a66440 is 0 bytes inside a block of size 2 alloc'd
==4154390==at 0x4839809: malloc (vg_replace_malloc.c:307)
==4154390==by 0x4035E4: run_child (utils.c:354)
==4154390==by 0x403C5B: run_ptests (utils.c:534)
==4154390==by 0x402C4D: main (main.c:223)
==4154390==
==4154390== Invalid write of size 8
==4154390==at 0x403618: run_child (utils.c:358)
==4154390==by 0x403C5B: run_ptests (utils.c:534)
==4154390==by 0x402C4D: main (main.c:223)
==4154390== Address 0x4a66448 is 6 bytes after a block of size 2 alloc'd
==4154390==at 0x4839809: malloc (vg_replace_malloc.c:307)
==4154390==by 0x4035E4: run_child (utils.c:354)
==4154390==by 0x403C5B: run_ptests (utils.c:534)
==4154390==by 0x402C4D: main (main.c:223)
==4154390==
==4154390== Syscall param execve(argv) points to unaddressable byte(s)
==4154390==at 0x4955C2B: execve (in /usr/lib64/libc-2.32.so)
==4154390==by 0x40365E: run_child (utils.c:368)
==4154390==by 0x403C5B: run_ptests (utils.c:534)
==4154390==by 0x402C4D: main (main.c:223)
==4154390== Address 0x4a66442 is 0 bytes after a block of size 2 alloc'd
==4154390==at 0x4839809: malloc (vg_replace_malloc.c:307)
==4154390==by 0x4035E4: run_child (utils.c:354)
==4154390==by 0x403C5B: run_ptests (utils.c:534)
==4154390==by 0x402C4D: main (main.c:223)
Signed-off-by: Adrian Freihofer
---
utils.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/utils.c b/utils.c
index bce9808..a23679a 100644
--- a/utils.c
+++ b/utils.c
@@ -351,12 +351,9 @@ read_child(void *arg)
static inline void
run_child(char *run_ptest, int fd_stdout, int fd_stderr)
{
- char **argv = malloc(sizeof(char) * 2);
+ char *const argv[2] = {run_ptest, NULL};
chdir(dirname(strdup(run_ptest)));
- argv[0] = run_ptest;
- argv[1] = NULL;
-
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54180): https://lists.yoctoproject.org/g/yocto/message/54180
Mute This Topic: https://lists.yoctoproject.org/mt/84352908/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [ptest-runner 2/5] mem: Fix memleak for ptest_opts
From: Adrian Freihofer
make && valgrind -s --leak-check=full ./ptest-runner -d tests/data2
==4154029== HEAP SUMMARY:
==4154029== in use at exit: 20 bytes in 2 blocks
==4154029== total heap usage: 45 allocs, 43 frees, 42,909 bytes allocated
==4154029==
==4154029== 20 (8 direct, 12 indirect) bytes in 1 blocks are definitely lost in
loss record 2 of 2
==4154029==at 0x4839809: malloc (vg_replace_malloc.c:307)
==4154029==by 0x40252D: str2array (main.c:70)
==4154029==by 0x402768: main (main.c:119)
==4154029==
==4154029== LEAK SUMMARY:
==4154029==definitely lost: 8 bytes in 1 blocks
==4154029==indirectly lost: 12 bytes in 1 blocks
==4154029== possibly lost: 0 bytes in 0 blocks
==4154029==still reachable: 0 bytes in 0 blocks
==4154029== suppressed: 0 bytes in 0 blocks
==4154029==
==4154029== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
With this patch valgrind reports 0 errors.
Signed-off-by: Adrian Freihofer
---
main.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/main.c b/main.c
index 467548e..e73626c 100644
--- a/main.c
+++ b/main.c
@@ -84,6 +84,25 @@ str2array(char *str, const char *delim, int *num)
return array;
}
+void cleanup_ptest_opts(struct ptest_options *opts)
+{
+ for (int i=0; i < opts->dirs_no; i++)
+ free(opts->dirs[i]);
+
+ free(opts->dirs);
+ opts->dirs = NULL;
+
+ if (opts->ptests) {
+ free(opts->ptests);
+ opts->ptests = NULL;
+ }
+
+ if (opts->xml_filename) {
+ free(opts->xml_filename);
+ opts->xml_filename = NULL;
+ }
+}
+
int
main(int argc, char *argv[])
{
@@ -98,7 +117,7 @@ main(int argc, char *argv[])
#endif
struct ptest_list *head, *run;
- struct ptest_options opts;
+ __attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options
opts;
opts.dirs = malloc(sizeof(char **) * 1);
CHECK_ALLOCATION(opts.dirs, 1, 1);
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54179): https://lists.yoctoproject.org/g/yocto/message/54179
Mute This Topic: https://lists.yoctoproject.org/mt/84352907/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [ptest-runner 1/5] git: Extend the gitignore
From: Adrian Freihofer Signed-off-by: Adrian Freihofer --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..ef07e6a --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ +*.o +ptest-runner +ptest-runner-test -- 2.20.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54178): https://lists.yoctoproject.org/g/yocto/message/54178 Mute This Topic: https://lists.yoctoproject.org/mt/84352906/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [ptest-runner 0/5] ptest: Various memory fixes and enhancements
This patch series provides some memory management fixes and corrected return code handling for ptest-runner2. Adrian Freihofer (4): git: Extend the gitignore mem: Fix memleak for ptest_opts mem: Simplify memory management mem: Refactor ptest_list cleanup Lukasz Majewski (1): main: Do not return number of failed tests when calling ptest-runner .gitignore | 3 +++ main.c | 33 - ptest_list.c | 13 - ptest_list.h | 8 +--- tests/ptest_list.c | 13 +++-- tests/utils.c | 22 +++--- utils.c| 11 --- 7 files changed, 58 insertions(+), 45 deletions(-) create mode 100644 .gitignore -- 2.20.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54177): https://lists.yoctoproject.org/g/yocto/message/54177 Mute This Topic: https://lists.yoctoproject.org/mt/84352905/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
