Created attachment 61033 [details]
bugdoc

Can confirm with m6 on WinXP
Is this really a dba-issue?

seems to be some memory corruption problem, but I don't have the slightest idea
so far how and where and why ...

fs->aw: Just guessing, and just FYI, at the moment: Your fix for issue 98788 (in
aw063_OOO310, integrated in m3) touched a few of the related files, in
particular fmtextcontrolshell.cxx, and some edit engine files. (I *suppose* the
latter are involved because in a non-product m42, where aw063 was not yet
integrated, I get a few assertions talking about incompatible SfxPoolItem types,
and those originate from the EditEngine.

fs->aw: The bug here occurs in OOO310.m3, and in DEV300.m43, but not in
OOO310.m2 and DEV300.m42. Coincidentally, CWS aw063 was integrated into
OOO310.m3 and DEV300.m43. While this is true for a number of other CWSes, too,
but none of those touched the files in question.

I suppose that what is an assertion in m42 (the fact that an SvxUnderlineItem is
put into a pool where an SvxTextLineItem is expected (or was it the other way
'round?)) now, in m43, causes a crash.

AW: In aw063 i canged the OPO (OutlinerParaObject, reimplemented it) to get it
RefCounted and COW (CopyOnWrite). Adapted all usages, but no changes were done
to ItemHandling or ItemPool handling of those objects. Adaptions mainly focused
on the removal of the Clone() of OPO which now uses a copy constructor. Maybe
the Pool gets deleted while the OPO still exists, could You check that?

fs->aw: Before your change in aw063, the code in
FmTextControlShell::executeAttributeDialog looked like this:
  {
    ::std::auto_ptr< SfxItemPool > pPool( EditEngine::CreatePool() );
    pPool->FreezeIdRanges();
    SfxItemSet aPureItems( *pPool );
    ...
  }
After your change, it looked like this:
  {
    SfxItemPool* pPool = EditEngine::CreatePool();
    pPool->FreezeIdRanges();
    SfxItemSet aPureItems( *pPool );
    ...
    SfxItemPool::Free(pPool);
  }

In particular, this implies that now the pool is freed before aPureItems is
destroyed. Unfortunately, the SfxItemSet destructor accesses its pool - and this
is what crashes here.

Next time you change something in foreign code, please at least once actually
*run* your changes. In this particular case, this would have crashed immediately
- and thus saved me much more time than it would have cost you. Thanks.

fixed in CWS cac31stopper4

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fcac31stopper4

AW->FS: Be ensured that i ran as much as possible. As You can see, i had to make
the destructor protected and add a ::free method to get lifetime control over
those pools (an age-old problem). I changed all constructor usages of pools as
carefully as possible in all Applications. After that i contacted testing to run
all automated tests again and tried to execute as much of the changed code as
possible.
So, maybe there is no automated test doing what lead to this error and You
should add one. I apologize for having overseen that the order of destruction in
this exaple really changed.

@aw: there exists an automatic test found exactly this issue.
However it's a database test and none run database tests in your CWS aw063.
Maybe next time an aw CWS arrived the qa we need to run all really all all all
tests we have.
Anyway qa found this regression so everything works as expected. ;-)

fs->msc: please verify in CWS cac31stopper4

verified in cws calc31stopper4

As far as issue 100349 concerned the bug still exists in master version OOo-dev 
3.1 .0 (OOO310m7 Build:9393) for Windows XP. After clicking ‘OK’ or ‘Cancel’ in 
‘Character’ dialog box error message “soffice.bin has encountered a problem and 
needs to close.  We are sorry for the inconvenience†appears twice, but formatting 
of the text in the text control is performing.

This issue is fixed in CWS calc31stopper4
(http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=OOO310/calc31stopper4
- sorry for the wrong URL above), which has been integrated into m8. So, it is
expected behavior for the bug to be present in m7 :)

Verified on OOo310m9 on WinXP and Fedora9
Closing
Li Meiying