Patrick Sanan writes:
> On Thu, Aug 4, 2016 at 10:18 AM, Dave May wrote:
>>
>>
>> On 4 August 2016 at 10:10, Patrick Sanan wrote:
>>>
>>> I have a patch that I got from Dave that he got from Jed which seems
>>> to be related to this. I'll make a PR.
>>
>>
>> Jed wrote this variant of the VTK vi
On Thu, Aug 4, 2016 at 10:18 AM, Dave May wrote:
>
>
> On 4 August 2016 at 10:10, Patrick Sanan wrote:
>>
>> I have a patch that I got from Dave that he got from Jed which seems
>> to be related to this. I'll make a PR.
>
>
> Jed wrote this variant of the VTK viewer so please mark him as a review
On 4 August 2016 at 10:10, Patrick Sanan wrote:
> I have a patch that I got from Dave that he got from Jed which seems
> to be related to this. I'll make a PR.
>
Jed wrote this variant of the VTK viewer so please mark him as a reviewer
for my bug fix.
>
>
> On Wed, Aug 3, 2016 at 8:18 PM, Moha
I have a patch that I got from Dave that he got from Jed which seems
to be related to this. I'll make a PR.
On Wed, Aug 3, 2016 at 8:18 PM, Mohammad Mirzadeh wrote:
> OK so I just ran the example under valgrind, and if I use two VecViews, it
> complains about following leak:
>
> ==66838== 24,802
OK so I just ran the example under valgrind, and if I use two VecViews, it
complains about following leak:
==66838== 24,802 (544 direct, 24,258 indirect) bytes in 1 blocks are
definitely lost in loss record 924 of 926
==66838==at 0x19EBB: malloc (in
/usr/local/Cellar/valgrind/3.11.0/lib/va
On Wed, Aug 3, 2016 at 10:59 AM, Matthew Knepley wrote:
> On Tue, Aug 2, 2016 at 12:40 PM, Mohammad Mirzadeh
> wrote:
>
>> I often use the memory usage information in log_view as a way to check on
>> memory leaks and so far it has worked perfect. However, I had long noticed
>> a false-positive r
On Tue, Aug 2, 2016 at 12:40 PM, Mohammad Mirzadeh
wrote:
> I often use the memory usage information in log_view as a way to check on
> memory leaks and so far it has worked perfect. However, I had long noticed
> a false-positive report in memory leak for Viewers, i.e. destruction count
> is alwa
I often use the memory usage information in log_view as a way to check on
memory leaks and so far it has worked perfect. However, I had long noticed
a false-positive report in memory leak for Viewers, i.e. destruction count
is always one less than creation.
Today, I noticed what seems to be a seco
