Opened 11 years ago
Closed 10 years ago
#9989 closed bug (fixed)
app server should not delete UtilityBitmap with delete
Reported by: | bonefish | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Servers/app_server | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
When building libbe with DEBUG=1
the app server runs into the following assertion:
418: DEBUGGER: Deleted referenceable object that's not on the stack (this: 0x400ddc8, stack_base: 0x688c7000, stack_end: 0x68907000) debug_server: Thread 418 entered the debugger: Debugger call: `Deleted referenceable object that's not on the stack (this: 0x400ddc8, stack_base: 0x688c7000, stack_end: 0x68907000) ' stack trace, current PC 0x63356114 commpage_syscall + 0x4: (0x68905da0) 0x17133fd _ZN14BReferenceableD2Ev + 0x129 (0x68905f20) 0x127f79e _ZN12ServerBitmapD2Ev + 0x80 (0x68905f50) 0x127f822 _ZN13UtilityBitmapD1Ev + 0x26 (0x68905f70) 0x127f846 _ZN13UtilityBitmapD0Ev + 0x1c (0x68905f90) 0x125e315 _ZN19BitmapDrawingEngine7SetSizeEll + 0xfb (0x68905ff0) 0x129e836 _ZN16DefaultDecorator19_GetBitmapForButtonEPN9Decorator3TabENS_9ComponentEbll + 0x14a (0x689060a0) 0x129ebba _ZN16DefaultDecorator9_DrawZoomEPN9Decorator3TabEb5BRect + 0xbc (0x68906110) 0x129dbeb _ZN16DefaultDecorator11DrawButtonsEPN9Decorator3TabERK5BRect + 0xd3 (0x68906180) 0x129f2f2 _ZN16DefaultDecorator8_DrawTabEPN9Decorator3TabE5BRect + 0x462 (0x68906300) 0x129caa4 _ZN9Decorator9_DrawTabsE5BRect + 0xc0 (0x68906360) 0x129d31b _ZN16DefaultDecorator4DrawE5BRect + 0x6b (0x689063a0) 0x1294e5a _ZN6Window11_DrawBorderEv + 0xee (0x689063f0) 0x12966c9 _ZN6Window17RedrawDirtyRegionEv + 0x5b (0x68906430) 0x128e701 _ZN12ServerWindow14_MessageLooperEv + 0x221 (0x689064c0) 0x12725ff _ZN13MessageLooper15_message_threadEPv + 0xf (0x689064e0) 0xde7947 thread_entry + 0x1c
BitmapDrawingEngine::SetSize()
deletes a UtilityBitmap
, which is a BReferenceable
, object with the delete
operator. The reference count is 1, so that the assertion in the BReferenceable
destructor is triggered.
Since it is impossible for the check to know whether this is erroneous use -- and the check itself is quite useful -- something else needs to be changed. One thing that comes to mind is using ReleaseReference()
instead. Adding a Delete()
method which could check the reference count, might be even nicer. Not sure, if adding a private delete
operator would be possible to explicitly prevent it from being called.
Change History (1)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Fixed in hrev48711.