Search by Tags

BSP Layers and Reference Images for Yocto Project Issue Tracker

 

The following table contains known issues, scheduled bug fixes, and feature improvements for the Toradex BSP Layers and Reference Images for Yocto Project.

The tickets are split into two major states:

  • Submitted (open): new features and bug fixes for BSP versions that have not yet been released. They may be scheduled for a specific release version; not planned; or in our backlog. All of them have one of the following states:
    • Known Issue: a bug or unexpected behavior that has been reported and is pending a fix. Once fixed, the status will transition to Fixed.
    • Feature Request: a new feature that may be added to a future release. Once released, the status will transition to New Feature.
  • Released (closed): new features and bug fixes for BSP versions that have already been released. All of them have one of the following states:
    • Fixed: a bug that has been fixed and released.
    • New Feature: something that didn't exist before and was added to a new release.


Any schedules are not guaranteed but reflect the current planning. The planning could be shifted due to priority changes.

Issues that are scheduled for a specific version will be integrated into the mentioned version of the BSP.

We will update this table continuously in order to always provide the latest state of our development plan. Please see also the Linux Support Strategy to learn more about the different releases.

Clear Filter
Issue #StatusSubjectModuleSubsystemWinCE OSSeveritySubmitted for Mainline

Not Planned
ELB-399Known IssueGstreamer/Nvgstplayer Memory LeakColibri T30, Apalis T30Multimedia, Video CodecsLowNo

Description: Each iteration of a movie H264 playback using gstreamer/nvgstplayer allocates a queue via NvMMQueueCreate(phQueue=0x4225f318, max_entries=32, entry-size=224, thread_safe=1) inside NVIDIA's binary only libnvmm_utils.so library which is never freed (such a function creates three pointers of total size 7392 + 28 + 32). Most probably there is a missing NvMMQueueDestroy() somewhere in the decoder handling.

Workaround: The easiest workaround would be to spawn a new gstreamer process for every movie being played as destroying that process after the playback will explicitly free any memory even if not previously implicitly having been freed. Alternatively our partner Antmicro hacked up a custom libnvmm_utils.so wrapper library to be loaded by LD_PRELOAD which may intercept NvMMQueueCreate() calls and adaptively revert to a static queue in order to prevent any memory leaks. While such a solution will of course be highly use-case dependant it should fully fix any leaking. Further investigation on NVIDIA's side is pending.