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.
