Bug 158317 - void SfxItemPool::unregisterSfxPoolItem(const SfxPoolItem &): Assertion `nullptr != ppRegisteredSfxPoolItems' failed.
Summary: void SfxItemPool::unregisterSfxPoolItem(const SfxPoolItem &): Assertion `null...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) alpha0+
Hardware: All All
: medium normal
Assignee: Armin Le Grand
Whiteboard: target:24.2.0
Depends on:
Blocks: Crash-Assert
  Show dependency treegraph
Reported: 2023-11-22 12:11 UTC by Caolán McNamara
Modified: 2023-12-30 13:01 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

reproducer (24 bytes, application/rtf)
2023-11-22 12:11 UTC, Caolán McNamara

Note You need to log in before you can comment on or make changes to this bug.
Description Caolán McNamara 2023-11-22 12:11:17 UTC
New assert seen with oss-fuzz since https://gerrit.libreoffice.org/c/core/+/159685 was merged

Steps to Reproduce:
1. ./instdir/program/soffice.bin --calc ~/demo.rtf

Actual Results:
core/svl/source/items/itempool.cxx:1134: void SfxItemPool::unregisterSfxPoolItem(const SfxPoolItem &): Assertion `nullptr != ppRegisteredSfxPoolItems' failed.

Expected Results:

Reproducible: Always

User Profile Reset: No

Additional Info:
Comment 1 Caolán McNamara 2023-11-22 12:11:40 UTC
Created attachment 190963 [details]
Comment 2 Armin Le Grand 2023-11-23 13:29:45 UTC
Indeed, Item with SerialNumber 781 WhichID 4036 (EditEngine) gets registered on another pool than it gets de-registered. Strange since it's an ItemSet member and ItemSet should not change the Pool during lifetime. Have to check...
Comment 3 Armin Le Grand 2023-11-23 13:47:38 UTC
Looks like MakeCharAttrib uses DirectPutItemInPool on an already shared Item. Not sure yet how that gets to an ItemSet with another pool then, but it looks like EditCharAttrib *uses* an own SfxPoolItem ptr internally to another Item, the one that gets registered by DirectPutItemInPool.
Somehow that EditCharAttrib could be shared in another ItemSet and the internal one (can be accessed anytime using EditCharAttrib::GetItem() is used.
Another case where there is no tooling/mechanism to hold an SfxPoolItem in a safe way, it would have to be held in an SfxItemSet...
Comment 4 Armin Le Grand 2023-11-23 14:01:37 UTC
It is not possible to call DirectRemoveItemFromPool in EditCharAttrib::~EditCharAttrib(), there is no info about the pool available.
Comment 5 Armin Le Grand 2023-11-23 21:02:13 UTC
Also not possible to use implCreateItemEntry/implCleanupItemEntry, that is tooling limited *by purpose* to svl/Item/ItemSet stuff.
But what I can do is to do that SfxPoolItemHolder I already talked/thought about. It is a helper that can safely hold a SfxPoolItem in cases where an SfxItemSet is too expensive. Think about it as a SfxItemSet for a single item. That solves the problem why DirectPutItemInPool/DirectRemoveItemFromPool is used in general (each usage is a 'compromize').
Trying to do that now, will be needed anyways and is missing in the Item/Pool concept all the time...
Comment 6 Armin Le Grand 2023-11-24 15:16:52 UTC
Should be solved with https://gerrit.libreoffice.org/c/core/+/159931, will see
Comment 7 Commit Notification 2023-11-25 15:14:45 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":


tdf#158317 fix cleanup of SfxPoolItems in editeng

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.