Page 1 of 1

SIGSEGV signal (forbidden memory area access) intercepted

Posted: Tue Apr 05, 2016 10:08 am
by amir
Hi all,

I'm using Code_Saturne (V. 4.0.4) for a LES simulation and I have a problem with the user routine usvort.

With synthetic eddy method, all is working fine but when I try to use usvort, I get the following error message :

No error detected during the verification of the parameters
for the vortex method (usvort).

SIGSEGV signal (forbidden memory area access) intercepted!

Call stack:
1: 0x2b0e1c4e9c6f <opal_memory_ptmalloc2_int_malloc+0x66f> (libopen-pal.so.6)
2: 0x2b0e1c4eafd2 <opal_memory_ptmalloc2_malloc+0x52> (libopen-pal.so.6)
3: 0x3b4fc6641b <> (libc.so.6)
4: 0x2b0e1a0dda9f <cs_base_fortran_bft_printf_to_c+0x5f> (libsaturne.so.0)
5: 0x2b0e1a215ff1 <+0x1ebff1> (libsaturne.so.0)
6: 0x3b4fc32900 <> (libc.so.6)
7: 0x2b0e21139d82 <psm_mq_ipeek+0x22> (libpsm_infinipath.so.1)
8: 0x2b0e20efb83c <ompi_mtl_psm_progress+0x6c> (mca_mtl_psm.so)
9: 0x2b0e1c46fe0a <opal_progress+0x4a> (libopen-pal.so.6)
10: 0x2b0e1bf36a6d <ompi_request_default_wait_all+0x23d> (libmpi.so.1)
11: 0x2b0e223d8ec8 <ompi_coll_tuned_sendrecv_nonzero_actual+0x1b8> (mca_coll_tuned.so)
12: 0x2b0e223e088f <ompi_coll_tuned_allgather_intra_recursivedoubling+0x12f> (mca_coll_tuned.so)
13: 0x2b0e1bf46857 <MPI_Allgather+0x167> (libmpi.so.1)
14: 0x2b0e1a10e629 <cs_parall_allgather_r+0xc9> (libsaturne.so.0)
15: 0x2b0e1a3d607a <vorpre_+0x7d6> (libsaturne.so.0)
16: 0x2b0e1a0a3313 <caltri_+0x25b3> (libsaturne.so.0)
17: 0x2b0e1a08c875 <cs_run+0x3e5> (libsaturne.so.0)
18: 0x2b0e1a08c9b5 <main+0x115> (libsaturne.so.0)
19: 0x3b4fc1ecdd <__libc_start_main+0xfd> (libc.so.6)
20: 0x402b39 <> (cs_solver)
End of stack



The all listing, usvort and user_parameters are attached.

Has anyone an idea on how should I fix it ?

Thank you in advance

Amir

Re: SIGSEGV signal (forbidden memory area access) intercepte

Posted: Tue Apr 05, 2016 1:13 pm
by Yvan Fournier
Hello,

I don't know if the vortex method has been used much recently, or even if it is still part of the validation suite... so it's hard to say whether the bug is on your side or not (at least doing a quick read).

Could you test your case on a debug build of the code (i.e. a build which uses --enable-debug at configure) ? The code reuns about 3x slower, but has additional instrumentationin this case, often allowing to catch errors earlier and thus helping with debugging.

Regards,

Yvan

Re: SIGSEGV signal (forbidden memory area access) intercepte

Posted: Tue Apr 12, 2016 5:06 pm
by amir
Hello Yvan,

Thank you for your reply,

I am new in Code_Saturne and am trying to debug this case with using the Code_Saturne version 4.0.0 installation guide (6.1. Debug builds).

First I created dbg file and I run the ../../code saturne-4.0.0/configure in this file, so some other files are came up.
I tried to continue with --prefix=/home/user/Code_Saturne/3.0/arch/dbg \ nevertheless I couldn’t find the dbg in this path.
Even for --with-med=/home/user/opt/med-3.0 \ I didn’t catch anything.

I don’t know if I’m trying in the right way so I would appreciate if you were able to help me with this issue to spell out the steps that I have to go through in order to debug this specific case.

Many thanks in advance.
Regards,
Amir

Re: SIGSEGV signal (forbidden memory area access) intercepte

Posted: Tue Apr 12, 2016 10:17 pm
by Yvan Fournier
Hello Amir,

I can try, but I have limited time an connectivity this week, so next week would be better for me.

It is a good thing you are trying to debug this yourself, but as the vortex method has not been used much recently, there might be a bug, so if you have a small test case which reproduces this, I can take a look next week also.

Also, is there a specific reason you prefer the vortex method to the SEM method ? Turbulence specialists seem divided over the merits or each, but the vortex method could be on the list of features to be removed in the future if our own advanced users/specialists do not use it anymore (I need to check with them too).

Regards,

Yvan

Re: SIGSEGV signal (forbidden memory area access) intercepte

Posted: Wed Apr 13, 2016 1:33 pm
by amir
Hello Yvan,

Actually I use SEM as an inlet condition, however in term of comparison, I would like to run a simulation with Vortex, and even with the Mapped Method.

In fact, I want to do some LES simulations for cavitation flow, so I don’t know which inlet condition is better compiled with cavitation subroutine?

There are several recommendations to use Mapped but I wish I could use tierce (or at least the both Mapped and SEM).

Thank you for your time.
Kind regards,
Amir