cppu/source/typelibtypelib.cxx, typelib_typedescription_register contains a data race that might cause crashes.
In short: typelib_typedescription_register replaces members of already stored type descriptions without synchronizing with other threads that might currently use those members.
Crash scenario is as follows:
* thread A is processing an IPC call involving an out parameter with struct type (the type description for this struct's bComplete member is 0 up to now)
** thread A is copying the C++ out parameter to the BinaryAny objects for transferring it via IPC, and calls _copyConstructStruct (copy.hxx)
** _copyConstructStruct copies member per member, using the type description's pMemberOffsets and ppTypeRefs member attributes
* at the same time thread B also needs this struct type for its work, and tries to complete the struct type description (complete(...) in typelib.cxx).
** after completing the type description, the completed description is registered via typelib_typedescription_register
** typelib_typedescription_register notices that the new description is complete, but the previously stored was not -> it calls typelib_typedescription_destructExtendedMembers(...) on the old, stored typedescription
** typelib_typedescription_destructExtendedMembers(...) deletes the memory used for the pMemberOffsets and ppTypeRefs members (while they are in use by thread A)
** typelib_typedescription_register replaces the members in the stored struct with those from the new struct
Depending on the timing, thread A accesses already freed memory (no crash), or sees already different data at the pMemberOffset/ppTypeRefs pointers. The latter case happened for me, pMemberOffsets was 0 and pMemberOffsets was 0, ie. have already been reused for something else.
My struct contained a long and a type member, and the code crashed since it wanted to copy the type member at offset 0, which contained a 1 -> access to memory 0x1 instead of just copying the 1 as long value.
The issue seems to be present in libreoffice 126.96.36.199 (at least from looking at the typelib code), I found the issue in libreoffice 188.8.131.52
Would be cool, if you submitted a patch to solve it: https://wiki.documentfoundation.org/Development/gerrit
(In reply to Buovjaga from comment #1)
> Would be cool, if you submitted a patch to solve it:
Would you like to submit a patch using the link above ?
A workaround could be to not delete the extended data members, but this would create a memory leak. I have no idea how to fix the issue.
@Stephan, would you mind taking a look at the description provided ?