Summary: | elf/tst-decorate-maps fails on ppc64el | ||
---|---|---|---|
Product: | glibc | Reporter: | Simon Chopin <simon.chopin> |
Component: | malloc | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | adhemerval.zanella |
Priority: | P2 | ||
Version: | 2.39 | ||
Target Milestone: | 2.40 | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Simon Chopin
2024-03-25 13:19:39 UTC
Does the kernel use 64k pages? (In reply to Andreas Schwab from comment #1) > Does the kernel use 64k pages? $ getconf PAGESIZE 65536 I guess it does. Thanks Andreas for pointing me to the page size. There's an assumption made in the test that the early allocation code will need to grow beyond the initial data page, as those extra pages would be the ones marked "[anon: glibc: loader malloc]". However, if the page size is large enough, I guess that assumption isn't valid anymore. I'll write a patch skipping this particular assertion if the page size is 64k or above. (In reply to Simon Chopin from comment #3) > Thanks Andreas for pointing me to the page size. > > There's an assumption made in the test that the early allocation code will > need to grow beyond the initial data page, as those extra pages would be the > ones marked "[anon: glibc: loader malloc]". However, if the page size is > large enough, I guess that assumption isn't valid anymore. > > I'll write a patch skipping this particular assertion if the page size is > 64k or above. I could reproduce it on a ppc64le VM, and it seems to what you described: the __minimal_malloc never issues the mmap because the initial data segment can supply the loader memory requirement. I think without a way to trigger the load mmap allocation, it would be better to just remove the 'loader malloc' check (it might be that we will need to adjust for possible different page sizes). Fixed on 2.40. |