[vtk-developers] Offscreen rendering OpenGL, linux, leaks memory

David Lonie david.lonie at kitware.com
Fri Jun 10 08:32:58 EDT 2016


Hey Dan,

Not sure what would be causing that, especially since valgrind isn't
complaining. Some ideas:

What drivers have you noticed this on? Is there a pattern to them? I could
see a leaking texture handle etc. on a software driver doing something like
this.

Has this been tested on all the major drivers? This would help narrow down
whether it's something on our side or theirs.

This is a shot in the dark, but try running this through apitrace (
https://github.com/apitrace/apitrace), then playback the trace and monitor
memory usage + the error log. Maybe something's funky in the OpenGL command
stream.

Beyond that, the debugging tools are failing us and I don't see many other
options than to start cutting out bits of the code to locate the problem.
See if the leak goes away when, e.g. vtkOpenGLRenderer::DeviceRender is
bypassed and go from there.

HTH,
Dave

On Thu, Jun 9, 2016 at 4:24 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:

> I did not have --show-leak-kinds=all. This is the new result:
>
> ==492== HEAP SUMMARY:
> ==492==     in use at exit: 113 bytes in 3 blocks
> ==492==   total heap usage: 28,104 allocs, 28,101 frees, 18,108,567 bytes
> allocated
> ==492==
> ==492== 24 bytes in 1 blocks are still reachable in loss record 1 of 3
> ==492==    at 0x4C2C857: malloc (vg_replace_malloc.c:291)
> ==492==    by 0xE42680D: XextCreateExtension (in
> /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0)
> ==492==    by 0x8AEBF37: ??? (in /usr/lib/nvidia-304/libGL.so.304.131)
> ==492==    by 0x105A05DF: ???
> ==492==
> ==492== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
> ==492==    at 0x4C2AAE8: calloc (vg_replace_malloc.c:618)
> ==492==    by 0xE62D68F: _dlerror_run (dlerror.c:141)
> ==492==    by 0xE62D197: dlsym (dlsym.c:70)
> ==492==    by 0x8B1410D: ??? (in /usr/lib/nvidia-304/libGL.so.304.131)
> ==492==    by 0x8D4471F: ??? (in /usr/lib/nvidia-304/libGL.so.304.131)
> ==492==    by 0x8D7561F: ???
> ==492==    by 0x8B2AAF4: ??? (in /usr/lib/nvidia-304/libGL.so.304.131)
> ==492==
> ==492== 57 bytes in 1 blocks are still reachable in loss record 3 of 3
> ==492==    at 0x4C2C857: malloc (vg_replace_malloc.c:291)
> ==492==    by 0x8B1134C: ??? (in /usr/lib/nvidia-304/libGL.so.304.131)
> ==492==    by 0x61642F656D6F682E: ???
> ==492==    by 0x732F617370696C6D: ???
> ==492==    by 0x61646376752F6371: ???
> ==492==    by 0x6C706D6178652D73: ???
> ==492==    by 0x2F6B61656C2F7364: ???
> ==492==    by 0x74762F646C697561: ???
> ==492==    by 0x79726F6D656D2D6A: ???
> ==492==
> ==492== LEAK SUMMARY:
> ==492==    definitely lost: 0 bytes in 0 blocks
> ==492==    indirectly lost: 0 bytes in 0 blocks
> ==492==      possibly lost: 0 bytes in 0 blocks
> ==492==    still reachable: 113 bytes in 3 blocks
> ==492==         suppressed: 0 bytes in 0 blocks
> ==492==
> ==492== For counts of detected and suppressed errors, rerun with: -v
> ==492== Use --track-origins=yes to see where uninitialised values come from
> ==492== ERROR SUMMARY: 292 errors from 5 contexts (suppressed: 0 from 0)
>
>
> On Thu, Jun 9, 2016 at 3:46 PM, Aashish Chaudhary <
> aashish.chaudhary at kitware.com> wrote:
>
>> Did you run with this option? (See the message below)
>>
>>  To see them, rerun with: --leak-check=full --show-leak-kinds=all
>>
>> On Thu, Jun 9, 2016 at 2:45 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>>
>>> I did run it, it does not report anything. This is the report for 10
>>> iterations. It was similar for 10000.
>>> Maybe the memory is allocated by the driver and not caught by valgrind.
>>>
>>> =24195== HEAP SUMMARY:
>>> ==24195==     in use at exit: 113 bytes in 3 blocks
>>> ==24195==   total heap usage: 28,105 allocs, 28,102 frees, 18,108,607
>>> bytes allocated
>>> ==24195==
>>> ==24195== LEAK SUMMARY:
>>> ==24195==    definitely lost: 0 bytes in 0 blocks
>>> ==24195==    indirectly lost: 0 bytes in 0 blocks
>>> ==24195==      possibly lost: 0 bytes in 0 blocks
>>> ==24195==    still reachable: 113 bytes in 3 blocks
>>> ==24195==         suppressed: 0 bytes in 0 blocks
>>> ==24195== Reachable blocks (those to which a pointer was found) are not
>>> shown.
>>> ==24195== To see them, rerun with: --leak-check=full
>>> --show-leak-kinds=all
>>> ==24195==
>>> ==24195== For counts of detected and suppressed errors, rerun with: -v
>>> ==24195== Use --track-origins=yes to see where uninitialised values come
>>> from
>>> ==24195== ERROR SUMMARY: 292 errors from 5 contexts (suppressed: 0 from
>>> 0)
>>>
>>>
>>> On Thu, Jun 9, 2016 at 2:24 PM, Bill Lorensen <bill.lorensen at gmail.com>
>>> wrote:
>>>
>>>> If you are on linux, can you run valgrind on this?
>>>>
>>>> Bill
>>>>
>>>> On Thu, Jun 9, 2016 at 1:37 PM, Dan Lipsa <dan.lipsa at kitware.com>
>>>> wrote:
>>>> > Hi all,
>>>> > Does anybody have seen or has advice on fixing the following bug.
>>>> > Thank you.
>>>> >
>>>> > http://www.vtk.org/Bug/view.php?id=16744
>>>> >
>>>> > I paste here a portion of the test I am using. The whole test is in
>>>> mantis.
>>>> >
>>>> > 10000 iterations of Render leak about 20MB according the reports from
>>>> the
>>>> > OS. The render window is kept around and the renderer and all other
>>>> objects
>>>> > are deleted and and re-added at each iteration.
>>>> >
>>>> > The same program does not leak for onscreen OpenGL or
>>>> offscreen/onscreen
>>>> > OpenGL2.
>>>> >
>>>> >
>>>> >
>>>> > void iteration(int i, vtkRenderWindow* renderWindow)
>>>> > {
>>>> >   vtkSmartPointer<vtkCylinderSource> cylinder =
>>>> >     vtkSmartPointer<vtkCylinderSource>::New();
>>>> >   cylinder->SetResolution(8);
>>>> >
>>>> >   vtkSmartPointer<vtkPolyDataMapper> cylinderMapper =
>>>> >     vtkSmartPointer<vtkPolyDataMapper>::New();
>>>> >   cylinderMapper->SetInputConnection(cylinder->GetOutputPort());
>>>> >
>>>> >   vtkSmartPointer<vtkActor> cylinderActor =
>>>> >     vtkSmartPointer<vtkActor>::New();
>>>> >   cylinderActor->SetMapper(cylinderMapper);
>>>> >   cylinderActor->GetProperty()->SetColor(1.0000, 0.3882, 0.2784);
>>>> >   cylinderActor->RotateX(30.0);
>>>> >   cylinderActor->RotateY(-45.0);
>>>> >
>>>> >   vtkSmartPointer<vtkRenderer> renderer =
>>>> >     vtkSmartPointer<vtkRenderer>::New();
>>>> >   renderer->AddActor(cylinderActor);
>>>> >   renderer->SetBackground(0.1, 0.2, 0.4);
>>>> >   // Zoom in a little by accessing the camera and invoking its "Zoom"
>>>> > method.
>>>> >   renderer->ResetCamera();
>>>> >
>>>> >   renderWindow->AddRenderer(renderer);
>>>> >   renderWindow->Render();
>>>> >   renderWindow->RemoveRenderer(renderer);
>>>> > }
>>>> >
>>>> > int main()
>>>> > {
>>>> >   vtkSmartPointer<vtkRenderWindow> renderWindow =
>>>> >     vtkSmartPointer<vtkRenderWindow>::New();
>>>> >   renderWindow->SetSize(200, 200);
>>>> >   //renderWindow->OffScreenRenderingOn();
>>>> >   for (int i = 0; i < 10000; ++i)
>>>> >     {
>>>> >     iteration(i, renderWindow);
>>>> >     if (i % 10 == 0)
>>>> >       {
>>>> >       std::cout << i << " ==== Iteration ====" << std::endl;
>>>> >       os_memory_usage();
>>>> >       }
>>>> >     }
>>>> >   return 0;
>>>> > }
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Powered by www.kitware.com
>>>> >
>>>> > Visit other Kitware open-source projects at
>>>> > http://www.kitware.com/opensource/opensource.html
>>>> >
>>>> > Search the list archives at:
>>>> http://markmail.org/search/?q=vtk-developers
>>>> >
>>>> > Follow this link to subscribe/unsubscribe:
>>>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Unpaid intern in BillsBasement at noware dot com
>>>>
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Search the list archives at:
>>> http://markmail.org/search/?q=vtk-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>>
>>>
>>
>>
>> --
>>
>>
>>
>> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.
>> *
>> *| http://www.kitware.com/company/team/chaudhary.html
>> <http://www.kitware.com/company/team/chaudhary.html>*
>>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160610/d3cd18e7/attachment-0001.html>


More information about the vtk-developers mailing list