[petsc-users] Error - Out of memory. This could be due to allocating too large an object or bleeding by not properly ...

[TAY wee-beng]

On 26/2/2016 1:56 AM, Barry Smith wrote:
>     Run a much smaller problem for a few time steps, making sure you free all the objects at the end, with the option -malloc_dump this will print all the memory that was not freed and hopefully help you track down which objects you forgot to free.
>
>    Barry
Hi,

I run a smaller problem and lots of things are shown in the log. How can 
I know which exactly are not freed from the memory?

Is this info helpful? Or should I run in a single core?

Thanks
>> On Feb 25, 2016, at 12:33 AM, TAY wee-beng <zonexo at gmail.com> wrote:
>>
>> Hi,
>>
>> I ran the code and it hangs again. However, adding -malloc_test doesn't seem to do any thing. The output (attached) is the same w/o it.
>>
>> Wonder if there's anything else I can do.
>> Thank you
>>
>> Yours sincerely,
>>
>> TAY wee-beng
>>
>> On 24/2/2016 11:33 PM, Matthew Knepley wrote:
>>> On Wed, Feb 24, 2016 at 9:28 AM, TAY wee-beng <zonexo at gmail.com> wrote:
>>>
>>> On 24/2/2016 11:18 PM, Matthew Knepley wrote:
>>>> On Wed, Feb 24, 2016 at 9:16 AM, TAY wee-beng <zonexo at gmail.com> wrote:
>>>>
>>>> On 24/2/2016 9:12 PM, Matthew Knepley wrote:
>>>>> On Wed, Feb 24, 2016 at 1:54 AM, TAY wee-beng <zonexo at gmail.com> wrote:
>>>>>
>>>>> On 24/2/2016 10:28 AM, Matthew Knepley wrote:
>>>>>> On Tue, Feb 23, 2016 at 7:50 PM, TAY wee-beng <zonexo at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I got this error (also attached, full) when running my code. It happens after a few thousand time steps.
>>>>>>
>>>>>> The strange thing is that for 2 different clusters, it stops at 2 different time steps.
>>>>>>
>>>>>> I wonder if it's related to DM since this happens after I added DM into my code.
>>>>>>
>>>>>> In this case, how can I find out the error? I'm thinking valgrind may take very long and gives too many false errors.
>>>>>>
>>>>>> It is very easy to find leaks. You just run a few steps with -malloc_dump and see what is left over.
>>>>>>
>>>>>>     Matt
>>>>> Hi Matt,
>>>>>
>>>>> Do you mean running my a.out with the -malloc_dump and stop after a few time steps?
>>>>>
>>>>> What and how should I "see" then?
>>>>>
>>>>> -malloc_dump outputs all unfreed memory to the screen after PetscFinalize(), so you should see the leak.
>>>>> I guess it might be possible to keep creating things that you freed all at once at the end, but that is less likely.
>>>>>
>>>>>     Matt
>>>>>   
>>>> Hi,
>>>>
>>>> I got the output. I have zipped it since it's rather big. So it seems to be from DM routines but can you help me where the error is from?
>>>>
>>>> Its really hard to tell by looking at it. What I do is remove things until there is no leak, then progressively
>>>> put thing back in until I have the culprit. Then you can think about what is not destroyed.
>>>>
>>>>    Matt
>>> Ok so let me get this clear. When it shows:
>>>
>>> [21]Total space allocated 1728961264 bytes
>>> [21]1861664 bytes MatCheckCompressedRow() line 60 in /home/wtay/Codes/petsc-3.6.3/src/mat/utils/compressedrow.c
>>> [21]16 bytes PetscStrallocpy() line 188 in /home/wtay/Codes/petsc-3.6.3/src/sys/utils/str.c
>>> [21]624 bytes ISLocalToGlobalMappingCreate() line 270 in /home/wtay/Codes
>>>
>>> ....
>>>
>>> Does it mean that it's simply allocating space ie normal? Or does it show that there's memory leak ie error?
>>>
>>> I gave the wrong option. That dumps everything. Lets just look at the leaks with -malloc_test.
>>>
>>>   Sorry about that,
>>>
>>>      Matt
>>>   
>>> If it's error, should I zoom in and debug around this time at this region?
>>>
>>> Thanks
>>>>   
>>>> Thanks.
>>>>>   
>>>>>> -- 
>>>>>> Thank you
>>>>>>
>>>>>> Yours sincerely,
>>>>>>
>>>>>> TAY wee-beng
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
>>>>>> -- Norbert Wiener
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
>>>>> -- Norbert Wiener
>>>>
>>>>
>>>>
>>>> -- 
>>>> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
>>>> -- Norbert Wiener
>>>
>>>
>>>
>>> -- 
>>> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
>>> -- Norbert Wiener
>> <ibm2d.err>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.7z
Type: application/octet-stream
Size: 28945 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160226/2fb65292/attachment-0001.obj>