On Thu, 18 Sep 2025 10:26:13 GMT, Kevin Walls <[email protected]> wrote:
>> Francesco Andreuzzi has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - nn >> - comment and rename > > Thanks - does that still have the same problem? > (Do you have the jtreg log from this one, to confirm I was looking at the > right address here...) > > > libjvm second seg: > core: > > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000006b23000 0x00007fa9ff881000 0x0000000000000000 > 0x0000000000e23000 0x0000000000e23000 R E 0x1000 > > > libjvm binary: > > LOAD 0x0000000000680180 0x0000000000681180 0x0000000000681180 > 0x0000000000e226c0 0x0000000000e226c0 R E 0x1000 > > > These figures look like they work, for that check which has been working for > gcc builds: > > ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, > page_size) > > left: core file memsize: 0x0000000000e23000 > right: lib mem size 0x0000000000e226c0 rounds to 0xe23000 > > Was core 1 different? Looks like a slightly smaller libjvm in that run (mem > size was 0e225c0 and the core contained a 0xe24000 size mapping, which was > the problem). Hi @kevinjwalls, I think that might be my fault. I rerun the test and I noticed the failure this time is not in `libjvm.so`, but in `libjimage.so`: hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5) % info proc mappings [...] 0x00007fa9ff0e4000 0x00007fa9ff0fd000 0x19000 0x8000 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so I think this happens by chance. I added the files from the new round to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3309729209
