Memory Overflow caused by view() function in Ubuntu20.04

120 views
Skip to first unread message

GAI Guodong

unread,
Oct 20, 2021, 7:23:08 PM10/20/21
to basilisk-fr
Hi,

I'd like to report a memory management problem using view(); function in the Ubuntu20.04 system.

It can be noted that when using view(); function in the code, especially when a large quantity of pictures are produced, the memory allocated by the function can not be freed successfully. The code will crash after the saturation of the memory and this is independent on which solver we use, we tried LBM/DLMFD/Navier-stokes, or the grid type, we tried Multi-grid/Octree.

Only the test on the Ubuntu20.04 gives this problem (we tried three different machines, of different owner, different installation date of Basilisk). The test code works well on Centos, Ubuntu18.04 with a good memory management and doesn't crash in the time of test. Same code used in these different systems and compiled using same commands.

I'd like to raise this problem because even we don't produce as many figures as the test case, the increase of the memory usage will largely reduce the performance of the code.


I prepare a minimal test case in the attachment for your examination.
Here is the information of my workstation:
Linux myname 5.11.0-38-generic #42~20.04.1-Ubuntu SMP Tue Sep 28 20:41:07 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

And the compile lines I used are:

Serial compile:
qcc test_view.c -o test_view -lm -L${BASILISK}/gl -lglutils -lfb_osmesa -lOSMesa -lGLU

MPI compile: CC99='mpicc -std=c99' qcc -Wall -O2 -D_MPI=1 test_view.c -o test_view -lm -L${BASILISK}/gl -lglutils -lfb_osmesa -lOSMesa -lGLU

test_view.c
beforre_crash.png

j.a.v...@gmail.com

unread,
Oct 21, 2021, 12:24:42 PM10/21/21
to basilisk-fr
Hallo Guodo....

I believe your issue maybe fixed with a patch to Basilisk's OSMesa framebuffer library I send some time ago.


download it to some `/path/to/patch`, then do

$ cd $BASILISK
$ darcs apply `/path/to/patch`/fbOSMesa
$ cd gl
$ make

Please test and report.

Antoon
Op donderdag 21 oktober 2021 om 01:23:08 UTC+2 schreef guodo...@gmail.com:

GAI Guodong

unread,
Oct 21, 2021, 3:16:39 PM10/21/21
to basilisk-fr
Hi Antoon,

Thanks so much for your response! I'm sorry that I'm not familiar with creating a patch.
Since the link you sent me leads to a page full of texts, do I need to create a file name: fbOSMesa containing those commands?
I did in this way and it says: darcs failed:  Bad patch bundle!

I'd like to request if you can send me the patch file direclty? Or how can I make a patch file of my own?

Best regards,
Guodong

j.a.v...@gmail.com

unread,
Oct 22, 2021, 9:40:00 AM10/22/21
to basilisk-fr
Hallo Guodong

You can download the patch using a bash command like so:


It creates a file with the patch called `fbOSMesa` in the current folder.

Antoon
Op donderdag 21 oktober 2021 om 21:16:39 UTC+2 schreef guodo...@gmail.com:

GAI Guodong

unread,
Oct 24, 2021, 6:51:18 PM10/24/21
to basilisk-fr
Dear Antoon,
I'm pleased to see that the memory management problem seems to be solved by your patch. This is really helpful!!
I have download your patch as you proposed and then restart my computer yesterday.
Today when I retry the test code, I see that each processor takes only 0.5% even after running for half an hour.
So I believe that the patch + restart can solve this problem.

Thanks again for your kind help and I enjoy so much the prompt help from our community of Basilisk.

Best regards,
Guodong

j.a.v...@gmail.com

unread,
Oct 25, 2021, 7:24:19 AM10/25/21
to basilisk-fr
Hallo Guodong,

I noticed this:

If I remove the call to the `clear()` function, the code crashes (FPE) unless I apply the patch.
Only then all seems fine. But if I add the call to `clear()` again, your memory issue resurfaces.

If I interrupt the memory-buggy program before the memory runs out, it is not killed properly.

So, it is seems to be a pretty nasty bug that I could also reproduce on Debian 11 and Arch linux.

Antoon
Op maandag 25 oktober 2021 om 00:51:18 UTC+2 schreef guodo...@gmail.com:

GAI Guodong

unread,
Oct 25, 2021, 6:29:36 PM10/25/21
to basilisk-fr
Dear Antoon,

Indeed, I also had the FPE when I remove the clear(); And I found that the clear(); could be replaced by a draw(); function.
Thank you for your verification on the Debian 11 and Arch linux. What do you think we could do about this bug? Using an old version of OSMesa?

Best,
Guodong
Reply all
Reply to author
Forward
Message has been deleted
0 new messages