[Mesa-users] Segfault when running the tutorial

Thu Aug 29 00:16:13 EDT 2019

how much ram do you have?

fxt

> On Aug 28, 2019, at 9:02 PM, Croxmor Moraga <rodrigo.moraga.merino at gmail.com> wrote:
> 
> Definetly the error keeps coming back, I tried to pause the simmulation by saving he model in exact steps, and then continue it in order to not use all the ram.
> But again this error appears:
> 
>       1980   8.190944  1.045E+04   3.811436   3.930292   6.944780   5.246980   0.000000   0.000001   0.242197   0.546969  -2.388539   1474      0
>    4.280315   3.462020   1.451594   3.257643   2.645408  -8.153359   1.697800   0.601459   0.032572   0.001010   0.411691   0.088654      5      0
>  4.6295E+07  19.435195   3.932739   2.376360   1.938100 -10.374456   0.000000   0.364665   0.000097  3.985E-01  4.134E-02  0.000E+00    varcontrol
>                                rel_E_err   -2.7903716746572331D-13
>                        log_rel_run_E_err      -10.3655190684861882
> 
>  png/hr_7m_prems_agb_001980.png/png
>  png/hr_7m_prems_agb_001985.png/png
>  png/hr_7m_prems_agb_001990.png/png
>  failed in allocate for Load1_eoselm_Table
>  Load1_eoselm_Table ierr        5014           2           4   1.1399999999999999      /home/rodrigo/mesa-r11701/data/eosDT_data/mesa-eosELM_zbar_01.14_abar_01.42.data
>  retry    1995
>  png/hr_7m_prems_agb_001995.png/png
>  failed in allocate for Load1_eoselm_Table
>  Load1_eoselm_Table ierr        5014           2           4   1.1399999999999999      /home/rodrigo/mesa-r11701/data/eosDT_data/mesa-eosELM_zbar_01.14_abar_01.42.data
>  retry    1996
>  failed in allocate for Load1_eoselm_Table
>  Load1_eoselm_Table ierr        5014           1           5   1.2000000000000000      /home/rodrigo/mesa-r11701/data/eosDT_data/mesa-eosELM_zbar_01.20_abar_01.44.data
>  retry    1996
> failed while reading header info /home/rodrigo/mesa-r11701/data/eosDT_data/mesa-eosELM_zbar_01.20_abar_01.44.data
> 
>                4.500000
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
> 
> Backtrace for this error:
> #0  0x7f82fd3810ff in ???
> #1  0x930270 in __eoselm_eval_MOD_do_interp_with_2nd_derivs
> at ../private/eoselm_eval.f90:974
> #2  0x9314da in __eoselm_eval_MOD_get_elm_for_ia_iz_table
> at ../private/eoselm_eval.f90:429
> #3  0x931e04 in do_interp2
> at ../private/eoselm_eval.f90:361
> #4  0x931e04 in __eoselm_eval_MOD_get_elm_for_iz
> at ../private/eoselm_eval.f90:306
> #5  0x932591 in do_interp2
> at ../private/eoselm_eval.f90:236
> #6  0x932591 in __eoselm_eval_MOD_get_elm_table_results
> at ../private/eoselm_eval.f90:175
> #7  0x93283e in __eoselm_eval_MOD_get_elm_for_eosdt
> at ../private/eoselm_eval.f90:84
> #8  0x8fb40b in __eosdt_eval_MOD_combine_for_eosdt
> at ../private/eosdt_eval.f90:1363
> #9  0x8fc33e in __eosdt_eval_MOD_get_level5_elm_with_helm_for_eosdt
> at ../private/eosdt_eval.f90:649
> #10  0x8fb59f in __eosdt_eval_MOD_combine_for_eosdt
> at ../private/eosdt_eval.f90:1424
> #11  0x8fc777 in __eosdt_eval_MOD_get_level4_dt2_for_eosdt
> at ../private/eosdt_eval.f90:566
> #12  0x8fb40b in __eosdt_eval_MOD_combine_for_eosdt
> at ../private/eosdt_eval.f90:1363
> #13  0x8fccd1 in __eosdt_eval_MOD_get_level3_for_eosdt
> at ../private/eosdt_eval.f90:359
> #14  0x8fb982 in __eosdt_eval_MOD_combine_for_eosdt
> at ../private/eosdt_eval.f90:1401
> #15  0x8fcfd2 in __eosdt_eval_MOD_get_level2_for_eosdt
> at ../private/eosdt_eval.f90:274
> #16  0x8fb982 in __eosdt_eval_MOD_combine_for_eosdt
> at ../private/eosdt_eval.f90:1401
> #17  0x8ff990 in __eosdt_eval_MOD_get_level1_for_eosdt
> at ../private/eosdt_eval.f90:218
> #18  0x8ffe5c in __eosdt_eval_MOD_get_eosdt_results
> at ../private/eosdt_eval.f90:144
> #19  0x8de5f7 in __eos_lib_MOD_eosdt_get
> at ../public/eos_lib.f90:558
> #20  0x4e263a in __micro_MOD_eos_get
> at ../private/micro.f90:705
> #21  0x63a4ec in get_brunt_b
> at ../private/brunt.f90:360
> #22  0x63ad44 in __brunt_MOD_do_brunt_b_mhm_form._omp_fn.0
> at ../private/brunt.f90:256
> #23  0x7f82fd9bb63d in gomp_thread_start
> at /root/sdk2/build/gcc/libgomp/team.c:120
> #24  0x7f82fd532163 in start_thread
> at /build/glibc-B9XfQf/glibc-2.28/nptl/pthread_create.c:486
> #25  0x7f82fd45adee in ???
> #26  0xffffffffffffffff in ???
> ./rn1: línea 8:  3206 Violación de segmento  (`core' generado) ./star
> DATE: 2019-08-28
> TIME: 23:38:52
> 
> ******************************************************************
> failed to create final.mod when running inlist_7M_prems_to_AGB_header
> ******************************************************************
> 
> Even though the plots and everything runs properly, it just that this error keeps interrupting my work.
> If there anything I can do to fix this?
> 
> On other hand, do you know if it is possible to install mesa in the Windows ubuntu terminal?
> Does anyone have already done this and worked properly?
> From beforehand, thanks.
> 
> El sáb., 24 ago. 2019 a las 23:01, Francis Timmes (<fxt44 at mac.com>) escribió:
> i’ve not seen this message from x11/pgstar before, 
> but my first guess is that your still low on memory.
> 
> again, please cc mesa-users on all replies.
> 
> fxt
> 
> 
> 
> 
> > On Aug 24, 2019, at 4:50 PM, Croxmor Moraga <rodrigo.moraga.merino at gmail.com> wrote:
> > 
> > Forget what I asked before jeje. It happens that I fixed it, by keeping the first windows that appears from pgstar once I created the model, and keep it open, the loaded one create the plots as normal.
> > In that case, anytime i decided to load a model I used, i should run a test model, conserve that window, and then load the desired model?
> > Or it is some method to fix that?
> > Thanks for your pacience, and good night.
> > 
> > El sáb., 24 ago. 2019 a las 19:03, Croxmor Moraga (<rodrigo.moraga.merino at gmail.com>) escribió:
> > But going back to my last problem, when I load that model I created before, and continued it. It runs, but the pgstar plots didn't appear, and instead this is written in my terminal.
> > PGPLOT /xw: Waiting for /home/rodrigo/mesasdk/lib/pgplot/pgxwin_server to start (timeout in 7 seconds).
> > PGPLOT /xw: Timed out waiting for program /home/rodrigo/mesasdk/lib/pgplot/pgxwin_server to start
> > PGPLOT /xw: Waiting for /home/rodrigo/mesasdk/lib/pgplot/pgxwin_server to start (timeout in 7 seconds).
> > PGPLOT /xw: Timed out waiting for program /home/rodrigo/mesasdk/lib/pgplot/pgxwin_server to start
> > 
> > Is that normal when I load a model, and because of that, I have to write something else in the code?
> > Or is just another ram memory problem?
> > 
> > El jue., 22 ago. 2019 a las 15:44, Croxmor Moraga (<rodrigo.moraga.merino at gmail.com>) escribió:
> > I did built my own, with oracle virtual machine on windows, created a ubuntu distribution
> > 
> > El jue., 22 ago. 2019 12:49, amber lauer via Mesa-users <mesa-users at lists.mesastar.org> escribió:
> > Jon, I think it's because he's running a VM. I make the VMESA virtual machine, and though I'm not sure if that's what he's running, but it's a known problem if you don't extend the default memory and OMP cores. The How-to immediately recommends this, but I should add a statement specifically about the error. Croxmor, are you running VMESA or did you build your own VM?
> > =================================
> > Dr. Amber Lauer
> > Postdoctoral Researcher
> > Triangle Universities Nuclear Lab
> > Duke University
> > amber.lauer at tunl.duke.edu
> > 
> > 
> > On Wed, Aug 21, 2019 at 6:51 PM Josiah Schwab via Mesa-users <mesa-users at lists.mesastar.org> wrote:
> > Hi Jon,
> > 
> > I'm haven't looked carefully at the chain of events that leads of the SIGSEGV, but after the eos table allocation fails MESA should stop more gracefully.  One of the eos routines wasn't properly reporting that it failed to its caller, a bug which I just fixed.
> > 
> > Josiah
> > _______________________________________________
> > mesa-users at lists.mesastar.org
> > https://lists.mesastar.org/mailman/listinfo/mesa-users
> > 
> > _______________________________________________
> > mesa-users at lists.mesastar.org
> > https://lists.mesastar.org/mailman/listinfo/mesa-users
> > 
> 