Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • chatty chatty
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 247
    • Issues 247
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 17
    • Merge requests 17
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Librem5
  • chattychatty
  • Issues
  • #264

Closed
Open
Created Jan 12, 2020 by Ruslan Marchenko@ruffDeveloper

libpurple is never properly closed

While not a critical memory leak (initialized once) - it still is flagged in all valgrind executions marking large heap of data as being leaked. libpurple_init sets core ops to close and destroy all resources however the actual call purple_core_quit (which then calls the core op chatty_purple_quit) is never executed. Not sure where exactly to place it. Init is called from application->window but neither window nor app has destructor (only stub destructor in app).

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking