Yocto Technical Team Minutes, Engineering Sync, for July 20, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner
Stephen Jolley
Armin Kuster
Jan-Simon Möller
Joshua Watt
Steve Sakoman
Trevor Gamblin
Scott Murray
Randy MacLeod
Richard Purdie
Martin Jansa (JaMa)
Michael Halstead
Bruce Ashfiled
Tony Tascioglu
Ross Burton
Alexandre Belloni
Paul Barker
Denys Dmytriyenko

== project status ==
- -m2 to be built this week (after pzstd included in buildtools tarball)
- 3.3.2 (hardknott) to QA after -m2 build
- proposal to add lz4c, zstd, and pzstd as required host commands
- architectural discussion on a change to the override syntax
- prserv still waiting on python asyncio issues
- AB-INT issues around ptest
- simpler test cases still required for multiconfig to resolve issues

== discussion ==
RP: syntax changes. we’re limited by not knowing definitively what and
what isn’t an override. leads to lots of caching and extra resources.
it would help speed things up. there are issues around backwards
compatibility, but it shouldn’t be a problem. the new character was
illegal previously (no clash). so with the backwards compatibility solved
it should be clear sailing (famous last words)
ScottM: sgtm, i like the syntax
RP: “feels” right, and it helps massively inside bitbake. how old would we
have to go back
ScottM: dunfell
RP: so if we backport this to dunfell then AGL should be helped
ScottM + J-SM: yes. we’d have to wait for a bunch of BSPs to adopt too
ScottM: can we mix and match old and new syntax?
RP: yes
ScottM: then we should be okay. AGL will be a good test case
JPEW: mix and match now, then make it required in the future?
RP: discussion ongoing
TrevorW: we started discussions on override syntax at OEDEM 2015, glad to see
it coming in
RP: my instinct is to bring it in quickly rather than have a long overlap. it
is used a lot in image filesystem code, also in tune features, qemu. the
package code relies heavily on the override syntax (package data). the tsc
generally thinks we should move forward. how long to wait before moving
forward?
AlexB: not too long. definitely before next lts and a little before
RP: which means now is a good time
PaulB: great idea. how about -m2? before or after?
RP: wanted -m2 last week, need new buildtools tarball, tempted to do it before
-m2
PaulB: ship it! (lol)
JPEW: at this point we’re just talking about converting the metadata?
RP: yes.
RP: tempted to do it for -m2.
RP: steve?
SS: sounds good, good idea to backport
RP: see discussion on oe-architecture

RP: Ross is proposing a function for bitbake-utils (layer_path()) for a layers
path to be extracted. why not a bblayersdir variable. core has this, sort
of. but maybe other layers could use this too. if you start encoding
paths like this, they get into the signatures (sigs depend on locations)
so path has to be in hash whitelisting variable. but path ends up in
signature file (for debugging). maybe have “add layer” like “add
task” that takes care of this. patches are on mailing list. we could
drop bbcollections variable that would be nice to drop (historic, predates
layers). it’d be nice to simplify some of the variables used in bitbake.
we force the priority to 5 (for no reason)
JPEW: priority levels has always been confusing
RP: this could make this go away
Denys: and there’s recipe priority
RP: and preferred, etc…
JPEW: and recipe priority only holds inside a layer
RP: one of the big issues with python2 → python3 was this sort of thing
JPEW: this could be easily backwards compatible?
RP: yes
PaulB: sounds like the right direction. layer.conf has always been confusing
(copy this boilerplate and it’ll work, don’t ask how) moving this into
bitbake would make it easier for users
Ross: i like getting rid of layer priority since this is a cause of lots
of issues since it works one day then stops a while later (after
bblayers.conf changes)
RP: behind the scenes bitbake does ugly stuff expanding layer dirs etc. so
this would get rid of that ugly code
ScottM: also backported to dunfell?
RP: more nervous backporting something like this
JPEW: probably wouldn’t be able to backport forcing the priority
PaulB: it’d be nice to have a branch of a layer support dunfell, hardknott,
and master all at the same time (without changes), but it probably won’t
be too hard
JPEW: yes, we do that too, and we go back a lot further. it’s possible
RP: i don’t want to block Ross’s patch and i think this would be good

ScottM: read-only prserv. moving the syncio loop creation. ran oe-selftest a
couple times. i don’t think it’s helping, still seeing failures with
the patches (and not without). i’ll need to double-check to make sure
these aren’t intermittent issues. do we want this feature bad enough
that doing it without the unification of the async-rpc code with the hash
equivalency is required? could we push that out to next release and just
do more minor tweaks for read-only mode for this release?
RP: i’m now worried about hash-equiv server as well. we run one on the
server but i think there’s gremlins there
JPEW: ScottM ping me on it, i think it should work, i’d like to help
ScottM: yea, i think it should work too. i think there’s a race in the
shutdown code. with enough load i think we’re running into something.
but i think it’s in the shutdown and solvable. i’m pretty sure i can
run enough load locally to mimic the behaviour of the AB.
RP: when i originally worked on this and we scaled AB, i had to do crazy load
tests. AB finds these failures
ScottM: was seeing loadavg of 800-900 on my local machine. it looked like
bitbake had shutdown during the build at one point. so it seems to match
the AB failures
PaulB: sounds like the failures i was seeing
ScottM: unfortunately the server tests don’t ever see these. they have to be
run on the whole build with a loaded build machine. so i think we should
do some for -m2 and then work on the rest for future releases/builds
RP: i’m not up-to-date on the asyncio stuff, but i've analyzed lots of
failures with bitbake shutdowns so i think i can help too
PaulB: i’ve moved off, but i’m happy to review patches or help brainstorm

ScottM: would it be possible to do a build on the AB with the auto-start
hash-equiv to see how that goes?
RP: if we put something into helper then we could try that
ScottM: we would lose some performance
JPEW: it would be a “throw-away” build
ScottM: okay, i’d like to try it to see how that would work
RP: AlexB can you set that up?
AlexB: sure
ScottB: bbhashserv = auto
RP: okay, do that and let scott know which build it is that’s got that
setting

ScottM: elc/yps?
TrevorW: working on it. we’ll do something, most likely a copy of the last
one but probably 3-days

PaulB: anyone looked at Deny’s email? (adding 5.10 kernel to dunfell)
ScottM: we’d really like to do it for AGL
J-SM: many customers have already done it so it’d be nice to do it in one place
Denys: kernel has a new lts every year, and dunfell is over a year old. this
is something coming from YP members requests. thanks for reviews. the next
yocto lts would have the same issue
PaulB: reminds me of hardware enablement kernels from ubuntu, in other words,
seems common among linux distros with long-term lts releases that last
longer than 1 year (i.e. kernel lts time frames)
Randy: sounds like this is a good and requested thing. are there any
downsides? effects on userspace?
Denys: userspace would be 5.4 but kernel would be 5.10. if we switch userspace
to 5.10 then everything has to rebuild (toolchain, glibc, which leads to
everything rebuilding)
RP: i think the goal is to not change the toolchain. the impact shouldn’t be
on SS (libc-headers causes toolchain updates). thanks Denys for getting
the ball rolling
Denys: i’d like to move it away from github and bring it under
git.yoctoproject.org
PaulB: the repos on git.yp.org are organized by headings, so maybe have a
heading for dunfell mixin layers
RP: sounds like something the tsc should think about
Denys: anyone want to do a mixin layer for gcc? gcc10 for dunfell? (i.e. a
newer toolchain)
<crickets>
Randy: sounds like a “no”. what’s the motivation?
Denys: some vendors would like to stay on dunfell (less work than moving to
master) but also test and build against newer tools
PaulB: newer toolchains always generate new warnings, errors… which leads to
lots of patches required everywhere. lots of effort to update to a newer
toolchain
Denys: true. like with all the -fcommon stuff
Randy: so vendors would have to wait for next lts and/or work towards master
PaulB: if dunfell gets extended for another 2 years then a newer u-boot mixin
layer would be useful (and we might as well make that public). but only if
dunfell is extended
Denys: to be clear: my understanding is that all these individual updates
should be done with individual mixin layers, not all done in one layer?
PaulB: yes, kernel, u-boot, are relatively self-contained, so should be able
to do as separate mixin layers

SS: any process/timeline for making that decision (dunfell extended?)
RP: comes down to funding. we’ve asked the members, but they haven’t
decided yet. i’m advocating for it and would like to see it

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 <lukma@...>
---
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);
=20
rc =3D run_ptests(run, opts, argv[0], stdout, stderr);
+ fprintf(stdout, "TOTAL: %d FAIL: %d\n", ptest_list_length(run), rc);
+ if (rc > 0)
+ rc =3D 0;
=20
ptest_list_free_all(&run);
=20
--=20
2.20.1

From: Adrian Freihofer <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 <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
=20
- struct ptest_list *head, *run;
+ struct ptest_list *head =3D NULL;
+ struct ptest_list *run =3D NULL;
__attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options =
opts;
=20
opts.dirs =3D malloc(sizeof(char **) * 1);
@@ -175,7 +176,7 @@ main(int argc, char *argv[])
=20
head =3D NULL;
for (i =3D 0; i < opts.dirs_no; i ++) {
- struct ptest_list *tmp;
+ struct ptest_list *tmp =3D NULL;
=20
tmp =3D get_available_ptests(opts.dirs[i], opts.timeout);
if (tmp =3D=3D NULL) {
@@ -211,7 +212,7 @@ main(int argc, char *argv[])
=20
run =3D filter_ptests(head, opts.ptests, ptest_num);
CHECK_ALLOCATION(run, (size_t) ptest_num, 1);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
=20
for (i =3D 0; i < ptest_exclude_num; i++)
@@ -219,7 +220,7 @@ main(int argc, char *argv[])
=20
rc =3D run_ptests(run, opts, argv[0], stdout, stderr);
=20
- ptest_list_free_all(run);
+ ptest_list_free_all(&run);
=20
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);
}
=20
-int
-ptest_list_free_all(struct ptest_list *head)
+void
+ptest_list_free_all(struct ptest_list **head)
{
- int i =3D 0;
struct ptest_list *p, *q;
=20
- VALIDATE_PTR_RINT(head);
-
- p =3D head;
+ p =3D *head;
while (p !=3D NULL) {
q =3D p;
p =3D p->next;
=20
ptest_list_free(q);
- i++;
}
-
- return i;
+ *head =3D NULL;
}
=20
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 =3D NULL; \
} while (0)
=20
-#define PTEST_LIST_FREE_ALL_CLEAN(x) \
- do { \
- ptest_list_free_all(x); \
- x =3D NULL; \
- } while (0)
-
#define PTEST_LIST_ITERATE_START(head, p) for (p =3D head->next; p !=3D =
NULL; p =3D p->next) {
#define PTEST_LIST_ITERATE_END }
=20
@@ -58,7 +52,7 @@ struct ptest_list {
=20
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 **);
=20
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 =3D ptest_list_alloc();
ck_assert(ptest_list_add(head, strdup("perl"), NULL, 1) !=3D NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -62,14 +62,15 @@ START_TEST(test_free_all)
struct ptest_list *head =3D NULL;
int i;
=20
- ck_assert(ptest_list_free_all(head) =3D=3D -1);
+ ptest_list_free_all(&head);
+ ck_assert(head =3D=3D NULL);
ck_assert(errno =3D=3D EINVAL);
=20
head =3D ptest_list_alloc();
for (i =3D 0; i < ptests_num; i++)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -87,7 +88,7 @@ START_TEST(test_length)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);
=20
ck_assert_int_eq(ptest_list_length(head), ptests_num);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -109,7 +110,7 @@ START_TEST(test_search)
for (i =3D ptests_num - 1; i >=3D 0; i--)
ck_assert(ptest_list_search(head, ptest_names[i]) !=3D NULL);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -141,7 +142,7 @@ START_TEST(test_remove)
ck_assert_int_eq(ptest_list_length(head), n);
=20
ck_assert(ptest_list_search(head, "busybox") !=3D NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
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 @@ START_TEST(test_get_available_ptests)
for (i =3D 0; ptests_not_found[i] !=3D NULL; i++)
ck_assert(ptest_list_search(head, ptests_not_found[i]) =3D=3D NULL);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
START_TEST(test_print_ptests)
{
- struct ptest_list *head;
+ struct ptest_list *head =3D NULL;
=20
char *buf;
size_t size =3D PRINT_PTEST_BUF_SIZE;
@@ -116,14 +116,14 @@ START_TEST(test_print_ptests)
=20
head =3D ptest_list_alloc();
ck_assert(print_ptests(head, fp) =3D=3D 1);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line =3D fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line !=3D NULL);
ck_assert(strcmp(line, PRINT_PTESTS_NOT_FOUND) =3D=3D 0);
=20
head =3D get_available_ptests(opts_directory, 1);
ck_assert(print_ptests(head, fp) =3D=3D 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line =3D fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line !=3D NULL);
ck_assert(strcmp(line, PRINT_PTESTS_AVAILABLE) =3D=3D 0);
@@ -144,7 +144,7 @@ END_TEST
START_TEST(test_filter_ptests)
{
struct ptest_list *head =3D get_available_ptests(opts_directory, 1);
- struct ptest_list *head_new;
+ struct ptest_list *head_new =3D NULL;
char *ptest_not_exists[] =3D {
"glib",
};
@@ -161,8 +161,8 @@ START_TEST(test_filter_ptests)
ck_assert(head_new !=3D NULL);
ck_assert(ptest_list_length(head_new) =3D=3D 3);
=20
- ptest_list_free_all(head);
- ptest_list_free_all(head_new);
+ ptest_list_free_all(&head);
+ ptest_list_free_all(&head_new);
}
END_TEST
=20
@@ -191,7 +191,7 @@ START_TEST(test_run_ptests)
=20
rc =3D run_ptests(head, opts, "test_run_ptests", fp_stdout, fp_stderr);
ck_assert(rc =3D=3D 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
=20
fclose(fp_stdout);
free(buf_stdout);
@@ -227,7 +227,7 @@ START_TEST(test_run_timeout_duration_ptest)
=20
test_ptest_expected_failure(head, timeout, "hang", search_for_timeout_a=
nd_duration);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -255,7 +255,7 @@ START_TEST(test_run_fail_ptest)
=20
test_ptest_expected_failure(head, timeout, "fail", search_for_fail);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -354,7 +354,7 @@ test_ptest_expected_failure(struct ptest_list *head, =
const int timeout, char *pr
fp_stdout
);
=20
- PTEST_LIST_FREE_ALL_CLEAN(filtered);
+ ptest_list_free_all(&filtered);
}
=20
fclose(fp_stdout);
diff --git a/utils.c b/utils.c
index a23679a..4737bcd 100644
--- a/utils.c
+++ b/utils.c
@@ -110,7 +110,7 @@ get_ptest_file(char **ptest_file, struct stat *st_buf=
, const char *main_dir,
struct ptest_list *
get_available_ptests(const char *dir, int global_timeout)
{
- struct ptest_list *head;
+ struct ptest_list *head =3D NULL;
struct stat st_buf;
=20
int n, i;
@@ -212,7 +212,7 @@ get_available_ptests(const char *dir, int global_time=
out)
free(namelist);
=20
if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head);
+ ptest_list_free_all(&head);
errno =3D saved_errno;
break;
}
@@ -282,7 +282,7 @@ filter_ptests(struct ptest_list *head, char **ptests,=
int ptest_num)
}
=20
if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head_new);
+ ptest_list_free_all(&head_new);
errno =3D saved_errno;
}=20
} while (0);
--=20
2.20.1

From: Adrian Freihofer <adrian.freihofer@...>

Removes the following warnings thrown by
make && valgrind -s --leak-check=3Dfull ./ptest-runner -d tests/data2

=3D=3D4154390=3D=3D Invalid write of size 8
=3D=3D4154390=3D=3D at 0x40360D: run_child (utils.c:357)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D Address 0x4a66440 is 0 bytes inside a block of size =
2 alloc'd
=3D=3D4154390=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307)
=3D=3D4154390=3D=3D by 0x4035E4: run_child (utils.c:354)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D
=3D=3D4154390=3D=3D Invalid write of size 8
=3D=3D4154390=3D=3D at 0x403618: run_child (utils.c:358)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D Address 0x4a66448 is 6 bytes after a block of size 2=
alloc'd
=3D=3D4154390=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307)
=3D=3D4154390=3D=3D by 0x4035E4: run_child (utils.c:354)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D
=3D=3D4154390=3D=3D Syscall param execve(argv) points to unaddressable by=
te(s)
=3D=3D4154390=3D=3D at 0x4955C2B: execve (in /usr/lib64/libc-2.32.so)
=3D=3D4154390=3D=3D by 0x40365E: run_child (utils.c:368)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D Address 0x4a66442 is 0 bytes after a block of size 2=
alloc'd
=3D=3D4154390=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307)
=3D=3D4154390=3D=3D by 0x4035E4: run_child (utils.c:354)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)

Signed-off-by: Adrian Freihofer <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 =3D malloc(sizeof(char) * 2);
+ char *const argv[2] =3D {run_ptest, NULL};
chdir(dirname(strdup(run_ptest)));
=20
- argv[0] =3D run_ptest;
- argv[1] =3D NULL;
-
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
--=20
2.20.1

From: Adrian Freihofer <adrian.freihofer@...>

make && valgrind -s --leak-check=3Dfull ./ptest-runner -d tests/data2

=3D=3D4154029=3D=3D HEAP SUMMARY:
=3D=3D4154029=3D=3D in use at exit: 20 bytes in 2 blocks
=3D=3D4154029=3D=3D total heap usage: 45 allocs, 43 frees, 42,909 bytes=
allocated
=3D=3D4154029=3D=3D
=3D=3D4154029=3D=3D 20 (8 direct, 12 indirect) bytes in 1 blocks are defi=
nitely lost in loss record 2 of 2
=3D=3D4154029=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307)
=3D=3D4154029=3D=3D by 0x40252D: str2array (main.c:70)
=3D=3D4154029=3D=3D by 0x402768: main (main.c:119)
=3D=3D4154029=3D=3D
=3D=3D4154029=3D=3D LEAK SUMMARY:
=3D=3D4154029=3D=3D definitely lost: 8 bytes in 1 blocks
=3D=3D4154029=3D=3D indirectly lost: 12 bytes in 1 blocks
=3D=3D4154029=3D=3D possibly lost: 0 bytes in 0 blocks
=3D=3D4154029=3D=3D still reachable: 0 bytes in 0 blocks
=3D=3D4154029=3D=3D suppressed: 0 bytes in 0 blocks
=3D=3D4154029=3D=3D
=3D=3D4154029=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: =
0 from 0)

With this patch valgrind reports 0 errors.

Signed-off-by: Adrian Freihofer <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;
}
=20
+void cleanup_ptest_opts(struct ptest_options *opts)
+{
+ for (int i=3D0; i < opts->dirs_no; i++)
+ free(opts->dirs[i]);
+
+ free(opts->dirs);
+ opts->dirs =3D NULL;
+
+ if (opts->ptests) {
+ free(opts->ptests);
+ opts->ptests =3D NULL;
+ }
+
+ if (opts->xml_filename) {
+ free(opts->xml_filename);
+ opts->xml_filename =3D NULL;
+ }
+}
+
int
main(int argc, char *argv[])
{
@@ -98,7 +117,7 @@ main(int argc, char *argv[])
#endif
=20
struct ptest_list *head, *run;
- struct ptest_options opts;
+ __attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options =
opts;
=20
opts.dirs =3D malloc(sizeof(char **) * 1);
CHECK_ALLOCATION(opts.dirs, 1, 1);
--=20
2.20.1

From: Adrian Freihofer <adrian.freihofer@...>

Signed-off-by: Adrian Freihofer <adrian.freihofer@...>
---
.gitignore | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..ef07e6a
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+*.o
+ptest-runner
+ptest-runner-test
--=20
2.20.1

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

--=20
2.20.1

A build flagged for QA (yocto-3.4_M2.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.4_M2.rc1


Build hash information:

bitbake: 13e2855bff6a6ead6dbd33c5be4b988aafcd4afa
meta-arm: 9efa3b5683a5dd7ebbf63ff31b889ed589ff7a9a
meta-gplv2: b3fa26bc777ec0136ce189d90123b50f6ee567b9
meta-intel: 94c097a82cf9167fa567c2af80d5e39a3fbbc11f
meta-mingw: 8f3b6e3772879dc2caec8fe249ce277fbb1aa55f
oecore: c4fc226c2e3856b942bb4f57ead21a64c3dc8c0d
poky: 1ad79313a5c3e6a453fbeb44caac5c5bbad46d3c


[RP sending manually as the original failed to get through]
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...

In message: RE: [yocto-kernel-cache] [yocto-5.10] nxp-imx8: Enable IMX_SCU_SOC config
on 16/07/2021 Wang, Xiaolei wrote:

Hi bruce

Can you help me merge this patch to yocto-kernel-cache branch yocto-5.10

The original patch didn't have a branch specified, so it somehow managed to
miss my filters.

this is now merged

Bruce

Thanks
Xiaolei

-----Original Message-----
From: linux-yocto@... <linux-yocto@...> On Behalf Of Xiaolei Wang
Sent: Friday, July 9, 2021 12:58 PM
To: bruce.ashfield@...
Cc: linux-yocto@...
Subject: [linux-yocto] [PATCH] nxp-imx8: Enable IMX_SCU_SOC config

Enable IMX_SCU_SOC config for imx8 get soc_id value and get revision, Because the SW workaround for i.MX8QM TKT340553 is required on the imx8qm board, it is necessary to set TKT340553_SW_WORKAROUND to true in tlbflush.h, otherwise the system will often encounter memory problems and cause hang

Signed-off-by: Xiaolei Wang <xiaolei.wang@...>
---
bsp/nxp-imx8/nxp-imx8.cfg | 1 +
1 file changed, 1 insertion(+)

diff --git a/bsp/nxp-imx8/nxp-imx8.cfg b/bsp/nxp-imx8/nxp-imx8.cfg index d9ea3caf..dbc77b3a 100644
--- a/bsp/nxp-imx8/nxp-imx8.cfg
+++ b/bsp/nxp-imx8/nxp-imx8.cfg
@@ -475,6 +475,7 @@ CONFIG_OF_OVERLAY=y
CONFIG_MAILBOX=y
CONFIG_IMX_MBOX=y
CONFIG_IMX_SCU=y
+CONFIG_IMX_SCU_SOC=y
CONFIG_IMX_DSP=y
CONFIG_IMX_SCU_PD=y
CONFIG_IIO=y
--
2.25.1

On Tue, Jul 20, 2021 at 8:25 AM forstevers via lists.yoctoproject.org
<steve=echodyne.com@...> wrote:

Trying to produce c++ versions of dmalloc libraries.The dmalloc recipe dmalloc_5.5.2.bb looks to be configured to build the c++ versions with:

'EXTRA_OECONF += "--enable-threads --enable-cxx --enable-shlib"'

But in the log.do_configure I see that the autoconf fails to find a c++ compiler, and I end up with the 'c' versions of the dmalloc library.

configure: configurations for the dmalloc library
configure: build utilities
checking for aarch64-xilinx-linux-gcc... aarch64-xilinx-linux-gcc --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether aarch64-xilinx-linux-gcc --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
checking for aarch64-xilinx-linux-gcc --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether aarch64-xilinx-linux-g++ --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
configure: WARNING: could not find C++ compiler

Any suggestions on how to get this recipe to build the requested c++ versions. Is there a dependency I can add in an append file to force it to recognize the compiler?

there should be a config.log generated in this component's build
directory which should have more information on what check failed and
perhaps some more errors to tell what went wrong.

On Sun, 2021-07-18 at 16:07 -0700, Tim Orling wrote:

The current code base uses Django 2.2.x which will go out of extended
support in April 2022, but also holds us back from updating a number of
dependencies.

Update to the current Django 3.2.5 LTS and also the latest Celery 5.1.2.
Celery 4 has not had any commits since 2020 and is unlikely to be
getting much more attention from the developers.

While we are at it, upgrade all of our dependencies to the latest
versions.

I don't have the skills to review this in detail but it sounds like a
good step forward for many different reasons, thanks!

Cheers,

Richard

I am generating eSDK for my image which includes meta-qt layer for graphics.
meta-qt uses python3 where as my meta layer uses python2
my meta layer uses python2-mako where as meta-qt layer uses python3-mako.
While generating eSDK both meta layers tries to install mako-render in /usr/bin which generate build error for eSDK generation.
Any suggestion how to resolve this issue.

Trying to produce c++ versions of dmalloc libraries.The dmalloc recipe dmalloc_5.5.2.bb looks to be configured to build the c++ versions with:

'EXTRA_OECONF += "--enable-threads --enable-cxx --enable-shlib"'

But in the log.do_configure I see that the autoconf fails to find a c++ compiler, and I end up with the 'c' versions of the dmalloc library.

configure: configurations for the dmalloc library
configure: build utilities
checking for aarch64-xilinx-linux-gcc... aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
checking for aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether aarch64-xilinx-linux-g++  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
configure: WARNING: could not find C++ compiler

Any suggestions on how to get this recipe to build the requested c++ versions. Is there a dependency I can add in an append file to force it to recognize the compiler?

Thanks...

Not deleting the source tree is the default behaviour. It sounds like
you've inherited rm_work, so if you want to not delete build trees
after completion then add the recipe name to RM_WORK_EXCLUDE.

Ross

On Mon, 19 Jul 2021 at 15:22, Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@...> wrote:

Hi Alex, RP, Mark,

I did some research on the subject in order to try to figure out what is going on.

1) I come to a similar conclusion with what found, but tried to look a bit deeper for the reason.

1.1) The reason that cross-prelink is not prelinking is, that for a quite some time by default everything is built with PIE mode by default and cross-prelink does not seem to be able to work on exe/libs compiled with PIE mode. So seeing the same behavior with and without prelinking is what I would expect as long as everything is compiled with PIE mode.

A more detailed analysis of my tests can be found on my not yet officially published site:

https://rlbl.me/prelink-1

https://rlbl.me/prelink-2

Alex:

Can you please rebuild your test images without PIE mode and re-run the tests?

Then we should have the 4 test cases:

prelinked-with-pie
no-prelink-with-pie
prelink-no-pie
no-prelink-no-pie

I guess then we can discuss what are the next steps.

In my opinion the current default settings, which compile close to everything in PIE mode, but invoke also cross-prelink do not make much sense.

The question is: "Do we want to drop cross-prelink, or do we want to drag it along and come up more fine-grained configuration options?"

We could e.g. exclude certain files from pre-linking.

IMHO cross-prelink still works, but not on exe/libs which were compiled in PIE mode.

Regards,

Robert