Issue 93215

Summary:	static Bitmap dtor SEGV
Product:	gsl	Reporter:	Stephan Bergmann <stephan.bergmann.secondary>
Component:	code	Assignee:	AOO issues mailing list <issues>
Status:	CONFIRMED ---	QA Contact:
Severity:	Trivial
Priority:	P3	CC:	hdu, issues, mst.ooo
Version:	DEV300m30
Target Milestone:	---
Hardware:	All
OS:	All
Issue Type:	DEFECT	Latest Confirmation in:	---
Developer Difficulty:	---

Description Stephan Bergmann 2008-08-28 15:45:59 UTC

At least on unxsoli4.pro DEV300m30 reproducible as follows:  In a non-buildenv
shell start soffice "-accept=pipe,name=$USER;urp" and in a buildenv shell cd
forms/qa/unoapi && dmake; after the dmake finishes terminate the office:

t@1 (l@1) terminated by signal SEGV (no mapping at the fault address)
[1] ImpBitmap::~ImpBitmap(this = ???) (optimized), at 0xfd6ef2e1 (line ~60) in
"impbmp.cxx"
[2] Bitmap::ImplReleaseRef(this = ???) (optimized), at 0xfd6af2b4 (line ~413) in
"bitmap.cxx"
[3] Bitmap::~Bitmap(this = ???) (optimized), at 0xfd6ae876 (line ~160) in
"bitmap.cxx"
[4] BitmapEx::~BitmapEx(this = ???) (optimized), at 0xfd6c2e90 (line ~187) in
"bitmapex.cxx"
[5] __SLIP.FINAL__A(0x8047c0c, 0x8047b64, 0xfef7e000, 0xfef83080, 0x8047b9c,
0xfeed49e2), at 0xf0e22a8b
[6] _exithandle(0xfeffa7d8, 0x8050a9b, 0x0, 0x8050a08, 0x8050c38, 0xfefd4914),
at 0xfeee1d2d
[7] exit(0x2, 0x8047c74, 0x8047cbe, 0x0, 0x8047cdc, 0x8047cf3), at 0xfeed49e2

The BitmapEx is SdPageObjectFadeNameNumberPrimitive::maFadeEffectIconBitmap
(sd/source/ui/slidesorter/view/SlsPageObjectViewObjectContact.cxx:1.23 l. 603),
the Bitmap is the BitmapEx::aMask member, and the ImpBitmap dtor tries to read
the mpSalBitmap vtable to execute the delete mpSalBitmap at
vcl/source/gdi/impbmp.cxx:1.12 l. 60.

Comment 1 philipp.lohmann 2008-09-06 13:50:18 UTC

static bitmaps are an obvious evil. All bitmaps must be destroyed before
DeInitVCL; if you really need a static instance, replace it with an empty one
which is probably less problematic.

Comment 2 mst.ooo 2008-09-11 10:55:00 UTC

i also found this issue (unxsoli4 m30); to reproduce it, it is sufficient to
just open draw/impress and then quit; same stacktrace

Comment 3 mst.ooo 2009-03-03 17:55:03 UTC

@af: i can't reproduce this any more in DEV300m42. did someone fix it?

Comment 4 groucho266 2009-03-04 07:11:41 UTC

I think that PL fixed something like this and also the slide sorter is now based
on the new drawing layer, which also could have made this crash go away.

Comment 5 Marcus 2017-05-20 11:33:09 UTC

Reset assigne to the default "issues@openoffice.apache.org".