Page MenuHome

not freed memory blocks on regular exiting
Closed, ResolvedPublic

Description

System Information
Linux 64 Debian Jessie - NVidia GTX 660 Ti

Blender Version
Broken: 2.77 (release), 2.76b

Short description of error
after quitting a fresh installation of the actual blender release via Ctrl-Q
an error occurs in the command line:

...
Error: Not freed memory blocks: 2, total unfreed memory 0.000732 MB
Blender quit

Exact steps for others to reproduce the error
with a fresh installation, without copying earlier setups

  1. call freshly installed blender from release download
  2. save user settings (to produce the 2.77 folder and subfolders etc)
  3. exit blender
  4. call blender
  5. exit via Ctrl-Q -> Error: Not freed memory blocks: 2, total unfreed memory 0.000732 MB
  6. call blender
  7. quit blender via closing window button of OS -> no error

Funny....
Probably some different treatment of the quitting processes... ??

Event Timeline

Norbert Krieg (nobi08) set Type to Bug.
Norbert Krieg (nobi08) created this task.
Norbert Krieg (nobi08) raised the priority of this task from to Needs Triage by Developer.
Bastien Montagne (mont29) triaged this task as Confirmed, Low priority.

This needs a win dev to check… probably some missing memfree in specific windows quit handling?

Can't redo this bug.
Tested on Windows7, official 2.77 release and master (d91316dc672dc1ee69fbd24d2f00124a24b75c6b)

When I confirmed a report T48057, it occurred only once.
I ran blender with --factory-startup option.

Windows 10 Pro 64bits
Blender version: 2.77 (sub 0), commit date: 2016-04-04 23:20, hash: 9c952bb

I'm also unsuccessful full in reproducing this one. Why is this tagged windows? original report came in on Linux 64 Debian Jessie ?

I've reproduced the bug on several builds from 2.57 to recent ones.

Run Blender with -d --factory-startup go directly to the File > Quit menu.

Accessing it from the Ctrl + Q shortcut doesn't cause the leak.

Win 7 64 bit.

Julian Eisel (Severin) claimed this task.
Julian Eisel (Severin) raised the priority of this task from Confirmed, Low to Confirmed, Medium.

Can easily recreate this using steps mentioned by @Vuk Gardašević (lijenstina).

Note: after some further testing related to a bug report, setting the operator_context in the space_info.py to EXEC_AREA causes the issue. If a confirmation pop-up is called, there is no memory leak.

layout.operator_context = 'EXEC_AREA'
if bpy.data.is_dirty and context.user_preferences.view.use_quit_dialog:
    layout.operator_context = 'INVOKE_SCREEN'  # quit dialog