segmentation fault error

kk415 · December 6, 2018, 10:48

Hello Foamers,

I am working on development of a new solver in openFoam and I am facing a very unusual problem right now, whenever I increase my grid size beyond a certain size I am getting segmentation fault ( core dumped ). However the solver works well in small grid size.

What could be the reason for this ?

usv001 · December 15, 2018, 22:40

Segmentation faults occur when a program tries to read a memory location that is not allocated for the program or write to a memory location that is read-only. So, judging from your problem, I am guessing that you may not have sufficient memory to run the case when the grid size is small. What is the size of your problem (mesh) and how much RAM do you have?

By the way, I am assuming that when you mean "small grid size" you are actually saying that the mesh has "fewer cells". If you are having problem with a smaller mesh but not a large one, then it is really strange.

Could you try to isolate the exact line in your solver which leads to the SegFault and post it so that people can help you better...

USV

kk415 · December 18, 2018, 01:45

Thanks USV for your answer.

I develop a dual grid solver, so my test case has two grids.

The small grid test case in which primary grid is of 2500 cells and secondary grid is 10000 cells run properly.

The large grid test case in which primary grid is of 40000 cells and secondary grid is 160000 cells gives the segFault error.

My ram is 30 GB. Also I tried to run a single grid solver (i.e. default solver of OpenFoam) for a test case of 250000, which also run fine.

How can I ensure that the reason of error is solely because of low memory? I checked the stats of processor and resources in the terminal by using top command it is showing 0.5% of memory usage and then suddenly goes to zero.

I am unable to fetch the exact line of error. The code is giving error when the header file is changing. If I merge two three header files then also it is working. But I can't merge all files in one.

raumpolizei · December 18, 2018, 03:40

Hello there,

difficult to say what is causing this error. I think it could be helpful to post the code (or at least a minimal example of it) where the segFault occurs.

RP

usv001 · December 23, 2018, 00:47

Hello Krishna,

As raumpolizei said, it is difficult to help you without seeing the code which causes the problem.

Quote:

Originally Posted by kk415

I am unable to fetch the exact line of error. The code is giving error when the header file is changing. If I merge two three header files then also it is working. But I can't merge all files in one.

I am not sure if I understand the above correctly. Could you please elaborate?

On a final note, in my experience, segFaults are common when you're not careful of your loop counters. For instance, let's say a Field only has n elements but if your loop tries to go beyond this and access element n+1, it may return a segFault if the memory location is protected by something else. Interestingly, in your situation, this may only happen for the larger case and not the smaller case. Nevertheless, it is still a bug. So, I suggest that you go through your loops as a first check. After that, check whether you're accessing each Field/List within its proper bounds.

USV

kk415 · December 23, 2018, 02:25

Hello All

Thanks for all your replies. And yes my problem was of stack memory. I am able to run big cases now. All I need to do is use command

ulimit -s unlimited

This increases the swap memory.

Hisham · December 23, 2018, 03:14

This might indicate you have a memory leak. Try using valgrind

kk415 · December 24, 2018, 22:47

Hi Hisam

I tried valgrind as you have suggested and find out there is leak of memory.

The error message is like this :

==10982== Warning: client switching stacks? SP change: 0x7fedf9260 --> 0x7fea4fa50
==10982== to suppress, use: --max-stackframe=3840016 or greater
==10982== Warning: client switching stacks? SP change: 0x7fea4fa50 --> 0x7fe7dea40
==10982== to suppress, use: --max-stackframe=2560016 or greater
==10982== Warning: client switching stacks? SP change: 0x7fe6a6230 --> 0x7fe435220
==10982== to suppress, use: --max-stackframe=2560016 or greater
==10982== further instances of this message will not be shown.
==10982== Invalid write of size 8
==10982== at 0x431FA9: main (in /home/Rajesh/OpenFOAM/Rajesh-2.3.1/platforms/linux64Gcc48DPOpt/bin/d_CLSVOFFoam)
==10982== Address 0x7fe435218 is on thread 1's stack
==10982==
==10982== Can't extend stack to 0x7fe4342c8 during signal delivery for thread 1:
==10982== no stack segment
==10982==
==10982== Process terminating with default action of signal 11 (SIGSEGV)
==10982== Access not within mapped region at address 0x7FE4342C8
==10982== at 0x431FA9: main (in /home/Rajesh/OpenFOAM/Rajesh-2.3.1/platforms/linux64Gcc48DPOpt/bin/d_CLSVOFFoam)
==10982== If you believe this happened as a result of a stack
==10982== overflow in your program's main thread (unlikely but
==10982== possible), you can try to increase the size of the
==10982== main thread stack using the --main-stacksize= flag.
==10982== The main thread stack size used in this run was 10485760.
==10982==
==10982== Process terminating with default action of signal 11 (SIGSEGV)
==10982== Access not within mapped region at address 0x7FE435191
==10982== at 0x4801661: _vgnU_freeres (vg_preloaded.c:58)
==10982== If you believe this happened as a result of a stack
==10982== overflow in your program's main thread (unlikely but
==10982== possible), you can try to increase the size of the
==10982== main thread stack using the --main-stacksize= flag.
==10982== The main thread stack size used in this run was 10485760.
==10982==
==10982== HEAP SUMMARY:
==10982== in use at exit: 193,293,096 bytes in 1,029,584 blocks
==10982== total heap usage: 1,085,813 allocs, 56,229 frees, 468,268,859 bytes allocated
==10982==
==10982== LEAK SUMMARY:
==10982== definitely lost: 0 bytes in 0 blocks
==10982== indirectly lost: 0 bytes in 0 blocks
==10982== possibly lost: 34,321,721 bytes in 1,017,167 blocks
==10982== still reachable: 158,971,375 bytes in 12,417 blocks
==10982== suppressed: 0 bytes in 0 blocks
==10982== Rerun with --leak-check=full to see details of leaked memory
==10982==
==10982== For counts of detected and suppressed errors, rerun with: -v
==10982== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 6)
Segmentation fault (core dumped)

Can you tell what it means ?

December 6, 2018, 10:48	segmentation fault error	#1
kk415 Senior Member krishna kant Join Date: Feb 2016 Location: Hyderabad, India Posts: 133 Rep Power: 10	Hello Foamers, I am working on development of a new solver in openFoam and I am facing a very unusual problem right now, whenever I increase my grid size beyond a certain size I am getting segmentation fault ( core dumped ). However the solver works well in small grid size. What could be the reason for this ?

December 15, 2018, 22:40		#2
usv001 Senior Member Join Date: Sep 2015 Location: Singapore Posts: 102 Rep Power: 10	Segmentation faults occur when a program tries to read a memory location that is not allocated for the program or write to a memory location that is read-only. So, judging from your problem, I am guessing that you may not have sufficient memory to run the case when the grid size is small. What is the size of your problem (mesh) and how much RAM do you have? By the way, I am assuming that when you mean "small grid size" you are actually saying that the mesh has "fewer cells". If you are having problem with a smaller mesh but not a large one, then it is really strange. Could you try to isolate the exact line in your solver which leads to the SegFault and post it so that people can help you better... USV kk415 likes this.

December 18, 2018, 03:40		#4
raumpolizei Member Join Date: Dec 2018 Location: Darmstadt, Germany Posts: 87 Rep Power: 7	Hello there, difficult to say what is causing this error. I think it could be helpful to post the code (or at least a minimal example of it) where the segFault occurs. RP kk415 likes this.

December 23, 2018, 03:14		#7
Hisham Senior Member Hisham Elsafti Join Date: Apr 2011 Location: Braunschweig, Germany Posts: 257 Blog Entries: 10 Rep Power: 17	This might indicate you have a memory leak. Try using valgrind alia and kk415 like this.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[OpenFOAM.org] compile error in dynamicMesh and thermophysicalModels libraries	NickG	OpenFOAM Installation	3	December 30, 2019 00:21
long error when using make-install SU2_AD.	tomp1993	SU2 Installation	3	March 17, 2018 06:25
DPM udf error	haghshenasfard	FLUENT	0	April 13, 2016 06:35
Ansys Fluent 13.0 UDF compilation problem in Window XP (32 bit)	Yogini	Fluent UDF and Scheme Programming	7	October 3, 2012 07:24
error while compiling the USER Sub routine	CFD user	CFX	3	November 25, 2002 15:16

December 18, 2018, 01:45		#3
kk415 Senior Member krishna kant Join Date: Feb 2016 Location: Hyderabad, India Posts: 133 Rep Power: 10	Thanks USV for your answer. I develop a dual grid solver, so my test case has two grids. The small grid test case in which primary grid is of 2500 cells and secondary grid is 10000 cells run properly. The large grid test case in which primary grid is of 40000 cells and secondary grid is 160000 cells gives the segFault error. My ram is 30 GB. Also I tried to run a single grid solver (i.e. default solver of OpenFoam) for a test case of 250000, which also run fine. How can I ensure that the reason of error is solely because of low memory? I checked the stats of processor and resources in the terminal by using top command it is showing 0.5% of memory usage and then suddenly goes to zero. I am unable to fetch the exact line of error. The code is giving error when the header file is changing. If I merge two three header files then also it is working. But I can't merge all files in one.

December 23, 2018, 02:25		#6
kk415 Senior Member krishna kant Join Date: Feb 2016 Location: Hyderabad, India Posts: 133 Rep Power: 10	Hello All Thanks for all your replies. And yes my problem was of stack memory. I am able to run big cases now. All I need to do is use command ulimit -s unlimited This increases the swap memory.

December 24, 2018, 22:47		#8
kk415 Senior Member krishna kant Join Date: Feb 2016 Location: Hyderabad, India Posts: 133 Rep Power: 10	Hi Hisam I tried valgrind as you have suggested and find out there is leak of memory. The error message is like this : ==10982== Warning: client switching stacks? SP change: 0x7fedf9260 --> 0x7fea4fa50 ==10982== to suppress, use: --max-stackframe=3840016 or greater ==10982== Warning: client switching stacks? SP change: 0x7fea4fa50 --> 0x7fe7dea40 ==10982== to suppress, use: --max-stackframe=2560016 or greater ==10982== Warning: client switching stacks? SP change: 0x7fe6a6230 --> 0x7fe435220 ==10982== to suppress, use: --max-stackframe=2560016 or greater ==10982== further instances of this message will not be shown. ==10982== Invalid write of size 8 ==10982== at 0x431FA9: main (in /home/Rajesh/OpenFOAM/Rajesh-2.3.1/platforms/linux64Gcc48DPOpt/bin/d_CLSVOFFoam) ==10982== Address 0x7fe435218 is on thread 1's stack ==10982== ==10982== Can't extend stack to 0x7fe4342c8 during signal delivery for thread 1: ==10982== no stack segment ==10982== ==10982== Process terminating with default action of signal 11 (SIGSEGV) ==10982== Access not within mapped region at address 0x7FE4342C8 ==10982== at 0x431FA9: main (in /home/Rajesh/OpenFOAM/Rajesh-2.3.1/platforms/linux64Gcc48DPOpt/bin/d_CLSVOFFoam) ==10982== If you believe this happened as a result of a stack ==10982== overflow in your program's main thread (unlikely but ==10982== possible), you can try to increase the size of the ==10982== main thread stack using the --main-stacksize= flag. ==10982== The main thread stack size used in this run was 10485760. ==10982== ==10982== Process terminating with default action of signal 11 (SIGSEGV) ==10982== Access not within mapped region at address 0x7FE435191 ==10982== at 0x4801661: _vgnU_freeres (vg_preloaded.c:58) ==10982== If you believe this happened as a result of a stack ==10982== overflow in your program's main thread (unlikely but ==10982== possible), you can try to increase the size of the ==10982== main thread stack using the --main-stacksize= flag. ==10982== The main thread stack size used in this run was 10485760. ==10982== ==10982== HEAP SUMMARY: ==10982== in use at exit: 193,293,096 bytes in 1,029,584 blocks ==10982== total heap usage: 1,085,813 allocs, 56,229 frees, 468,268,859 bytes allocated ==10982== ==10982== LEAK SUMMARY: ==10982== definitely lost: 0 bytes in 0 blocks ==10982== indirectly lost: 0 bytes in 0 blocks ==10982== possibly lost: 34,321,721 bytes in 1,017,167 blocks ==10982== still reachable: 158,971,375 bytes in 12,417 blocks ==10982== suppressed: 0 bytes in 0 blocks ==10982== Rerun with --leak-check=full to see details of leaked memory ==10982== ==10982== For counts of detected and suppressed errors, rerun with: -v ==10982== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 6) Segmentation fault (core dumped) Can you tell what it means ?