https://bugs.kde.org/show_bug.cgi?id=398028
--- Comment #10 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- I was able to reproduce the crash with the provided library, thanks. Here is the analysis of the crash: After loading the cfi information, we check that the range [cfsi_minavma, cfsi_maxavma] is fully inside the union of all the r-x mapping of the loaded debug info, which seems a reasonable invariant to check. However, in the case of libopenblas, there are 2 r-x mappings, but there is a 'hole' between these 2 r-x mappings. This means that the cfsi_fits check fails, as we do not find a r-x mapping to cover a part of the cfsi min/max range. Here is the detailed data (with some more tracing added in debuginfo.c to show the cfsi range and the uncovered part): --11075-- cfsi range 0x58ca020-0x777c860 --11075-- Uncovered 0x58d1000-0x58d3fff Valgrind debuginfo noted mappings of libopenblas 0x57dc000-0x791dfff r-- 0x58ca000-0x58d0fff r-x => sz 0x7000, i.e. 28672, corresponding to first r-x in objdump below 0x58d4000-0x777cfff r-x => sz 0x1ea9000, i.e. 32149504, corresponding to second r-w in objdump below 0x777d000-0x78e9fff r-- 0x78eb000-0x7907fff rw- OS mapping /proc/xxxx/maps 057dc000-058ca000 r--p 00000000 08:16 1835432 /home/philippe/valgrind/littleprogs/cfsi/libopenblasp-r0.3.3.so 058ca000-058d1000 r-xp 000ee000 08:16 1835432 /home/philippe/valgrind/littleprogs/cfsi/libopenblasp-r0.3.3.so 058d1000-058d4000 ---p 000f5000 08:16 1835432 /home/philippe/valgrind/littleprogs/cfsi/libopenblasp-r0.3.3.so 058d4000-0777d000 r-xp 000f5000 08:16 1835432 /home/philippe/valgrind/littleprogs/cfsi/libopenblasp-r0.3.3.so 0777d000-078ea000 r--p 01f9e000 08:16 1835432 /home/philippe/valgrind/littleprogs/cfsi/libopenblasp-r0.3.3.so 078ea000-078eb000 ---p 0210e000 08:16 1835432 /home/philippe/valgrind/littleprogs/cfsi/libopenblasp-r0.3.3.so 078eb000-07908000 rw-p 0210b000 08:16 1835432 /home/philippe/valgrind/littleprogs/cfsi/libopenblasp-r0.3.3.so 07908000-0791e000 r--p 0212c000 08:16 1835432 /home/philippe/valgrind/littleprogs/cfsi/libopenblasp-r0.3.3.so valgrind aspacemgr of libopenblas --15252:0: aspacem (9,544,12) /home/philippe/valgrind/littleprogs/cfsi/libopenblasp-r0.3.3.so ... --15252:0: aspacem 34: file 00057dc000-00058c9fff 974848 r---- d=0x816 i=1835432 o=0 (9,544) --15252:0: aspacem 35: file 00058ca000-00058d0fff 28672 r-x-- d=0x816 i=1835432 o=974848 (9,544) --15252:0: aspacem 36: file 00058d1000-00058d3fff 12288 ----- d=0x816 i=1835432 o=1003520 (9,544) --15252:0: aspacem 37: file 00058d4000-000777cfff 30m r-x-- d=0x816 i=1835432 o=1003520 (9,544) --15252:0: aspacem 38: file 000777d000-00078e9fff 1495040 r---- d=0x816 i=1835432 o=33153024 (9,544) --15252:0: aspacem 39: file 00078ea000-00078eafff 4096 ----- d=0x816 i=1835432 o=34660352 (9,544) --15252:0: aspacem 40: file 00078eb000-0007907fff 118784 rw--- d=0x816 i=1835432 o=34648064 (9,544) --15252:0: aspacem 41: file 0007908000-000791dfff 90112 r---- d=0x816 i=1835432 o=34783232 (9,544) objdump program header: ... LOAD off 0x00000000000ee000 vaddr 0x00000000000ee000 paddr 0x00000000000ee000 align 2**12 filesz 0x0000000000006e90 memsz 0x0000000000006e90 flags r-x LOAD off 0x00000000000f5000 vaddr 0x00000000000f8000 paddr 0x00000000000f8000 align 2**12 filesz 0x0000000001ea886d memsz 0x0000000001ea886d flags r-x ... All the above is consistent. I have checked in the cfsi trace, and there is no cfi information that is valid for the r-x hole. So, as far as I can see, the invariant check that fails is (still) too strong : Julian did a change the 17 of August in this invariant. Before, it was checking that the cfsi range was fully inside a single r-x mapping. After the change, the check verifies that the range is inside the union of all r-x mapping, but in the case of libopenblas, we have a hole between the 2 r-x mappings, but there is no cfsi information in this hole. The search in cfsi information is I believe not really depending that there is no overlap between different cfsi_min/max avma range: as long as no cfsi is referencing the hole in the r-x mapping, a 'cfsi hole' will be inserted by ML_(finish_CFSI_arrays): a search for an IP in the r-x hole will then lead to the cfsi_hole, which makes the search fail, and so the next di info (that have possibly filled the r-x hole with another mapping) will then succeed : find_DiCfSI does not do a dichotomic search on the cfsi array when the searched ip is outside of cfsi_min/max avma. But when the search ip is in this cfsi range, but the dichotomic search fails, the search continues in the next debug info list entry. So, in summary, I think we need to check that all cfsi entries are inside the union of r-x mapping (which might be expensive to check?). We should not check that the full cfsi range is inside the union of r-x mapping, due to such r-x hole in which we have no cfsi info. It would be nice to understand how to generate a (small) shared lib that contains such a r-x hole. -- You are receiving this mail because: You are watching all bug changes.