Opened 8 weeks ago

Closed 8 days ago

#15135 closed bug (fixed)

static destruction order problem in mediakit

Reported by: pulkomandy Owned by: leavengood
Priority: normal Milestone: Unscheduled
Component: Kits/Media Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

I have an app crashing on exit.

the MediaRosterUndertaker (a static object) is destroyed when my main thread is terminating. It signals the media roster looper to terminate.

When terminating, the media roster notified the Media Kit that it is gone (to remove all nodes from the app from the media graph). However, to do this it uses the sPortPool, which is also statically allocated. It seems the port pool has already been destroyed at this point, so the thread just crashes.

I couldn't find much info about the port pool, my guess it that it's there for performance reasons (no need to create a new port everytime we do something). Wold it be ok to avoid using it in media roster termination? Or is there a way to make the destruction order more safe?

Attachments (1)

ACE-27602-debug-02-07-2019-20-35-23.report (20.3 KB ) - added by pulkomandy 8 weeks ago.

Download all attachments as: .zip

Change History (4)

comment:1 by leavengood, 10 days ago

Owner: changed from nobody to leavengood
Status: newassigned

I have been just looking at the port pool stuff in relation to keeping the BufferCache clean when ports disappear, so I will look at this. Plus it seems like an anti-pattern to me at this point to have statically allocated objects in a library, certainly for the case of the port pool (the MediaRosterUndertaker is pretty clever though.)

Do you have a minimal case which replicates this, or I suppose I can replicate it with media_client or MediaPlayer? I do wonder why they do not crash in the same way.

comment:2 by leavengood, 10 days ago

This seems related to #5120 and the fix Axel made, but I think the port pool was missed: hrev34906. I am logging this here mostly as a record for myself.

comment:3 by waddlesplash, 8 days ago

Resolution: fixed
Status: assignedclosed

Fix merged in hrev53381.

Note: See TracTickets for help on using tickets.