search

TeamCOMPAS / COMPAS

COMPAS rapid binary population synthesis code
http://compas.science
MIT License
65 stars 66 forks source link

Segmentation Fault (Core Dumped) Encountered in COMPAS V3.0 with "--common-envelope-formalism TWO_STAGE" #1184

Closed lee0517-hub closed 2 months ago

lee0517-hub commented 2 months ago

Describe the bug When using the latest version of COMPAS V3.0 with the option "--common-envelope-formalism TWO_STAGE", the calculation stops within 10,000 samples, and the terminal reports an error: "Segmentation fault (core dumped)". Subsequently, using GDB for debugging, I found that the program crashes in the integrate_adaptive part of the BaseBinaryStar::CalculateMassTransferOrbit function. Since this issue did not occur with version V02.45, I directly copied the old version's code into the new version but then found that the function BaseBinaryStar::CalculateGammaAngularMomentumLoss_Static also causes the program to crash.

Label the issue urgency_moderate

To Reproduce ./COMPAS --common-envelope-alpha 0.9192428354321582 --wolf-rayet-multiplier 0.9200386565850202 --number-of-systems 100000 --initial-mass-function KROUPA --mass-ratio-distribution SANA2012 --semi-major-axis-distribution SANA2012 --metallicity-distribution LOGUNIFORM --critical-mass-ratio-prescription GE20 --tides-prescription PERFECT --remnant-mass-prescription FRYER2022 --common-envelope-formalism TWO_STAGE --common-envelope-allow-radiative-envelope-survive False --common-envelope-allow-immediate-RLOF-post-CE-survive False --chemically-homogeneous-evolution-mode OPTIMISTIC --pulsational-pair-instability-prescription STARTRACK

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Versioning (please complete the following information): I am unsure whether this issue only occurs on my computer. My configuration is:

Additional context valgrind output: 12563: Stars merged: (MainSequence>_0.7 -> Carbon-Oxygen_White_Dwarf) + (MainSequence>_0.7 -> Naked_Helium_Star_MS) ==619546== Invalid read of size 8 ==619546== at 0x14C5516: BaseBinaryStar::CalculateMassTransferOrbit(double, double, BinaryConstituentStar&, double) (BaseBinaryStar.cpp:1897) ==619546== by 0x14C3E84: BaseBinaryStar::ResolveCommonEnvelopeEvent() (BaseBinaryStar.cpp:1646) ==619546== by 0x14C9214: BaseBinaryStar::EvaluateBinary(double) (BaseBinaryStar.cpp:2524) ==619546== by 0x14CA4E3: BaseBinaryStar::Evolve() (BaseBinaryStar.cpp:2721) ==619546== by 0x1614915: BinaryStar::Evolve() (BinaryStar.h:50) ==619546== by 0x15ABF64: EvolveBinaryStars() (main.cpp:682) ==619546== by 0x15AE407: main (main.cpp:898) ==619546== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==619546== ==619546== ==619546== Process terminating with default action of signal 11 (SIGSEGV) ==619546== Access not within mapped region at address 0x0 ==619546== at 0x14C5516: BaseBinaryStar::CalculateMassTransferOrbit(double, double, BinaryConstituentStar&, double) (BaseBinaryStar.cpp:1897) ==619546== by 0x14C3E84: BaseBinaryStar::ResolveCommonEnvelopeEvent() (BaseBinaryStar.cpp:1646) ==619546== by 0x14C9214: BaseBinaryStar::EvaluateBinary(double) (BaseBinaryStar.cpp:2524) ==619546== by 0x14CA4E3: BaseBinaryStar::Evolve() (BaseBinaryStar.cpp:2721) ==619546== by 0x1614915: BinaryStar::Evolve() (BinaryStar.h:50) ==619546== by 0x15ABF64: EvolveBinaryStars() (main.cpp:682) ==619546== by 0x15AE407: main (main.cpp:898) ==619546== If you believe this happened as a result of a stack ==619546== overflow in your program's main thread (unlikely but ==619546== possible), you can try to increase the size of the ==619546== main thread stack using the --main-stacksize= flag. ==619546== The main thread stack size used in this run was 8388608.

ilyamandel commented 2 months ago

Thank you for the report! @jeffriley and I should be online starting next week, will take a look ASAP.

On Mon, 19 Aug 2024, 4:04 pm lee0517-hub, @.***> wrote:

Describe the bug When using the latest version of COMPAS V3.0 with the option "--common-envelope-formalism TWO_STAGE", the calculation stops within 10,000 samples, and the terminal reports an error: "Segmentation fault (core dumped)". Subsequently, using GDB for debugging, I found that the program crashes in the integrate_adaptive part of the BaseBinaryStar::CalculateMassTransferOrbit function. Since this issue did not occur with version V02.45, I directly copied the old version's code into the new version but then found that the function BaseBinaryStar::CalculateGammaAngularMomentumLoss_Static also causes the program to crash.

Label the issue urgency_moderate

To Reproduce ./COMPAS --common-envelope-alpha 0.9192428354321582 --wolf-rayet-multiplier 0.9200386565850202 --number-of-systems 100000 --initial-mass-function KROUPA --mass-ratio-distribution SANA2012 --semi-major-axis-distribution SANA2012 --metallicity-distribution LOGUNIFORM --critical-mass-ratio-prescription GE20 --tides-prescription PERFECT --remnant-mass-prescription FRYER2022 --common-envelope-formalism TWO_STAGE --common-envelope-allow-radiative-envelope-survive False --common-envelope-allow-immediate-RLOF-post-CE-survive False --chemically-homogeneous-evolution-mode OPTIMISTIC --pulsational-pair-instability-prescription STARTRACK

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Versioning (please complete the following information): I am unsure whether this issue only occurs on my computer. My configuration is:

  • OS: Ubuntu 22.04.4 LTS
  • COMPAS 03.00.02
  • gcc.exec (GCC) 13.1.0
  • Boost v1.82

Additional context valgrind output: 12563: Stars merged: (MainSequence>0.7 -> Carbon-Oxygen_White_Dwarf) + (Main_Sequence>_0.7 -> Naked_Helium_Star_MS) ==619546== Invalid read of size 8 ==619546== at 0x14C5516: BaseBinaryStar::CalculateMassTransferOrbit(double, double, BinaryConstituentStar&, double) (BaseBinaryStar.cpp:1897) ==619546== by 0x14C3E84: BaseBinaryStar::ResolveCommonEnvelopeEvent() (BaseBinaryStar.cpp:1646) ==619546== by 0x14C9214: BaseBinaryStar::EvaluateBinary(double) (BaseBinaryStar.cpp:2524) ==619546== by 0x14CA4E3: BaseBinaryStar::Evolve() (BaseBinaryStar.cpp:2721) ==619546== by 0x1614915: BinaryStar::Evolve() (BinaryStar.h:50) ==619546== by 0x15ABF64: EvolveBinaryStars() (main.cpp:682) ==619546== by 0x15AE407: main (main.cpp:898) ==619546== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==619546== ==619546== ==619546== Process terminating with default action of signal 11 (SIGSEGV) ==619546== Access not within mapped region at address 0x0 ==619546== at 0x14C5516: BaseBinaryStar::CalculateMassTransferOrbit(double, double, BinaryConstituentStar&, double) (BaseBinaryStar.cpp:1897) ==619546== by 0x14C3E84: BaseBinaryStar::ResolveCommonEnvelopeEvent() (BaseBinaryStar.cpp:1646) ==619546== by 0x14C9214: BaseBinaryStar::EvaluateBinary(double) (BaseBinaryStar.cpp:2524) ==619546== by 0x14CA4E3: BaseBinaryStar::Evolve() (BaseBinaryStar.cpp:2721) ==619546== by 0x1614915: BinaryStar::Evolve() (BinaryStar.h:50) ==619546== by 0x15ABF64: EvolveBinaryStars() (main.cpp:682) ==619546== by 0x15AE407: main (main.cpp:898) ==619546== If you believe this happened as a result of a stack ==619546== overflow in your program's main thread (unlikely but ==619546== possible), you can try to increase the size of the ==619546== main thread stack using the --main-stacksize= flag. ==619546== The main thread stack size used in this run was 8388608.

— Reply to this email directly, view it on GitHub https://github.com/TeamCOMPAS/COMPAS/issues/1184, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5BVOAWEIGQYRCZO3BAXLZSH3OJAVCNFSM6AAAAABMX44FGWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ3TGNBVGE2DCNI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

jeffriley commented 2 months ago

The problem here is that m_Accretor is a null pointer in BaseBinaryStar::CalculateMassTransferOrbit(). m_Accretor is set in BaseBinaryStar::CalculateMassTransfer(), but it is set after we exit because both stars are in RLOF. I think the two stage CE code uses m_Accretor - whereas the previous CE code didn't. I think m_Accretor needs to be set as appropriate (twice) in BaseBinaryStar::ResolveCommonEnvelopeEvent().

I can look at this tomorrow.

Duplicate using:

./compas --common-envelope-formalism TWO_STAGE --random-seed 5842

Jeff

-- Dr Jeff Riley Monash University, Australia Ph: +61 (0)407 811 282 @.***

On Mon, 19 Aug 2024 at 10:34, Ilya Mandel @.***> wrote:

Thank you for the report! @jeffriley and I should be online starting next week, will take a look ASAP.

On Mon, 19 Aug 2024, 4:04 pm lee0517-hub, @.***> wrote:

Describe the bug When using the latest version of COMPAS V3.0 with the option "--common-envelope-formalism TWO_STAGE", the calculation stops within 10,000 samples, and the terminal reports an error: "Segmentation fault (core dumped)". Subsequently, using GDB for debugging, I found that the program crashes in the integrate_adaptive part of the BaseBinaryStar::CalculateMassTransferOrbit function. Since this issue did not occur with version V02.45, I directly copied the old version's code into the new version but then found that the function BaseBinaryStar::CalculateGammaAngularMomentumLoss_Static also causes the program to crash.

Label the issue urgency_moderate

To Reproduce ./COMPAS --common-envelope-alpha 0.9192428354321582 --wolf-rayet-multiplier 0.9200386565850202 --number-of-systems 100000 --initial-mass-function KROUPA --mass-ratio-distribution SANA2012 --semi-major-axis-distribution SANA2012 --metallicity-distribution LOGUNIFORM --critical-mass-ratio-prescription GE20 --tides-prescription PERFECT --remnant-mass-prescription FRYER2022 --common-envelope-formalism TWO_STAGE --common-envelope-allow-radiative-envelope-survive False --common-envelope-allow-immediate-RLOF-post-CE-survive False --chemically-homogeneous-evolution-mode OPTIMISTIC --pulsational-pair-instability-prescription STARTRACK

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Versioning (please complete the following information): I am unsure whether this issue only occurs on my computer. My configuration is:

  • OS: Ubuntu 22.04.4 LTS
  • COMPAS 03.00.02
  • gcc.exec (GCC) 13.1.0
  • Boost v1.82

Additional context valgrind output: 12563: Stars merged: (MainSequence>0.7 -> Carbon-Oxygen_White_Dwarf) + (Main_Sequence>_0.7 -> Naked_Helium_Star_MS) ==619546== Invalid read of size 8 ==619546== at 0x14C5516: BaseBinaryStar::CalculateMassTransferOrbit(double, double, BinaryConstituentStar&, double) (BaseBinaryStar.cpp:1897) ==619546== by 0x14C3E84: BaseBinaryStar::ResolveCommonEnvelopeEvent() (BaseBinaryStar.cpp:1646) ==619546== by 0x14C9214: BaseBinaryStar::EvaluateBinary(double) (BaseBinaryStar.cpp:2524) ==619546== by 0x14CA4E3: BaseBinaryStar::Evolve() (BaseBinaryStar.cpp:2721) ==619546== by 0x1614915: BinaryStar::Evolve() (BinaryStar.h:50) ==619546== by 0x15ABF64: EvolveBinaryStars() (main.cpp:682) ==619546== by 0x15AE407: main (main.cpp:898) ==619546== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==619546== ==619546== ==619546== Process terminating with default action of signal 11 (SIGSEGV) ==619546== Access not within mapped region at address 0x0 ==619546== at 0x14C5516: BaseBinaryStar::CalculateMassTransferOrbit(double, double, BinaryConstituentStar&, double) (BaseBinaryStar.cpp:1897) ==619546== by 0x14C3E84: BaseBinaryStar::ResolveCommonEnvelopeEvent() (BaseBinaryStar.cpp:1646) ==619546== by 0x14C9214: BaseBinaryStar::EvaluateBinary(double) (BaseBinaryStar.cpp:2524) ==619546== by 0x14CA4E3: BaseBinaryStar::Evolve() (BaseBinaryStar.cpp:2721) ==619546== by 0x1614915: BinaryStar::Evolve() (BinaryStar.h:50) ==619546== by 0x15ABF64: EvolveBinaryStars() (main.cpp:682) ==619546== by 0x15AE407: main (main.cpp:898) ==619546== If you believe this happened as a result of a stack ==619546== overflow in your program's main thread (unlikely but ==619546== possible), you can try to increase the size of the ==619546== main thread stack using the --main-stacksize= flag. ==619546== The main thread stack size used in this run was 8388608.

— Reply to this email directly, view it on GitHub https://github.com/TeamCOMPAS/COMPAS/issues/1184, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAD5BVOAWEIGQYRCZO3BAXLZSH3OJAVCNFSM6AAAAABMX44FGWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ3TGNBVGE2DCNI>

. You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/TeamCOMPAS/COMPAS/issues/1184#issuecomment-2296981573, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGM5XNW4X4R4OD2TFRLNBELZSINAVAVCNFSM6AAAAABMX44FGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWHE4DCNJXGM . You are receiving this because you were mentioned.Message ID: @.***>

jeffriley commented 2 months ago

Ah, wait. The accretor is passed in p_Accretor, but I think we forgot to change all occurrences of m_Accretor to p_Accretor in this line in BaseBinaryStar::CalculateMassTransferOrbit():

integrate_adaptive(controlled_stepper , ode{ p_DonorMass, p_Accretor.Mass(), p_FractionAccreted, m_Accretor->IsDegenerate() }, x, 0.0, p_DeltaMassDonor, p_DeltaMassDonor / 1000.0);

If I make that change the problem seems to be resolved. I'll push a fix later today.

Jeff

-- Dr Jeff Riley Monash University, Australia Ph: +61 (0)407 811 282 @.***

On Mon, 19 Aug 2024 at 15:43, Jeff Riley @.***> wrote:

The problem here is that m_Accretor is a null pointer in BaseBinaryStar::CalculateMassTransferOrbit(). m_Accretor is set in BaseBinaryStar::CalculateMassTransfer(), but it is set after we exit because both stars are in RLOF. I think the two stage CE code uses m_Accretor - whereas the previous CE code didn't. I think m_Accretor needs to be set as appropriate (twice) in BaseBinaryStar::ResolveCommonEnvelopeEvent().

I can look at this tomorrow.

Duplicate using:

./compas --common-envelope-formalism TWO_STAGE --random-seed 5842

Jeff

-- Dr Jeff Riley Monash University, Australia Ph: +61 (0)407 811 282 @.***

On Mon, 19 Aug 2024 at 10:34, Ilya Mandel @.***> wrote:

Thank you for the report! @jeffriley and I should be online starting next week, will take a look ASAP.

On Mon, 19 Aug 2024, 4:04 pm lee0517-hub, @.***> wrote:

Describe the bug When using the latest version of COMPAS V3.0 with the option "--common-envelope-formalism TWO_STAGE", the calculation stops within 10,000 samples, and the terminal reports an error: "Segmentation fault (core dumped)". Subsequently, using GDB for debugging, I found that the program crashes in the integrate_adaptive part of the BaseBinaryStar::CalculateMassTransferOrbit function. Since this issue did not occur with version V02.45, I directly copied the old version's code into the new version but then found that the function BaseBinaryStar::CalculateGammaAngularMomentumLoss_Static also causes the program to crash.

Label the issue urgency_moderate

To Reproduce ./COMPAS --common-envelope-alpha 0.9192428354321582 --wolf-rayet-multiplier 0.9200386565850202 --number-of-systems 100000 --initial-mass-function KROUPA --mass-ratio-distribution SANA2012 --semi-major-axis-distribution SANA2012 --metallicity-distribution LOGUNIFORM --critical-mass-ratio-prescription GE20 --tides-prescription PERFECT --remnant-mass-prescription FRYER2022 --common-envelope-formalism TWO_STAGE --common-envelope-allow-radiative-envelope-survive False --common-envelope-allow-immediate-RLOF-post-CE-survive False --chemically-homogeneous-evolution-mode OPTIMISTIC --pulsational-pair-instability-prescription STARTRACK

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Versioning (please complete the following information): I am unsure whether this issue only occurs on my computer. My configuration is:

  • OS: Ubuntu 22.04.4 LTS
  • COMPAS 03.00.02
  • gcc.exec (GCC) 13.1.0
  • Boost v1.82

Additional context valgrind output: 12563: Stars merged: (MainSequence>0.7 -> Carbon-Oxygen_White_Dwarf) + (Main_Sequence>_0.7 -> Naked_Helium_Star_MS) ==619546== Invalid read of size 8 ==619546== at 0x14C5516: BaseBinaryStar::CalculateMassTransferOrbit(double, double, BinaryConstituentStar&, double) (BaseBinaryStar.cpp:1897) ==619546== by 0x14C3E84: BaseBinaryStar::ResolveCommonEnvelopeEvent() (BaseBinaryStar.cpp:1646) ==619546== by 0x14C9214: BaseBinaryStar::EvaluateBinary(double) (BaseBinaryStar.cpp:2524) ==619546== by 0x14CA4E3: BaseBinaryStar::Evolve() (BaseBinaryStar.cpp:2721) ==619546== by 0x1614915: BinaryStar::Evolve() (BinaryStar.h:50) ==619546== by 0x15ABF64: EvolveBinaryStars() (main.cpp:682) ==619546== by 0x15AE407: main (main.cpp:898) ==619546== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==619546== ==619546== ==619546== Process terminating with default action of signal 11 (SIGSEGV) ==619546== Access not within mapped region at address 0x0 ==619546== at 0x14C5516: BaseBinaryStar::CalculateMassTransferOrbit(double, double, BinaryConstituentStar&, double) (BaseBinaryStar.cpp:1897) ==619546== by 0x14C3E84: BaseBinaryStar::ResolveCommonEnvelopeEvent() (BaseBinaryStar.cpp:1646) ==619546== by 0x14C9214: BaseBinaryStar::EvaluateBinary(double) (BaseBinaryStar.cpp:2524) ==619546== by 0x14CA4E3: BaseBinaryStar::Evolve() (BaseBinaryStar.cpp:2721) ==619546== by 0x1614915: BinaryStar::Evolve() (BinaryStar.h:50) ==619546== by 0x15ABF64: EvolveBinaryStars() (main.cpp:682) ==619546== by 0x15AE407: main (main.cpp:898) ==619546== If you believe this happened as a result of a stack ==619546== overflow in your program's main thread (unlikely but ==619546== possible), you can try to increase the size of the ==619546== main thread stack using the --main-stacksize= flag. ==619546== The main thread stack size used in this run was 8388608.

— Reply to this email directly, view it on GitHub https://github.com/TeamCOMPAS/COMPAS/issues/1184, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAD5BVOAWEIGQYRCZO3BAXLZSH3OJAVCNFSM6AAAAABMX44FGWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ3TGNBVGE2DCNI>

. You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/TeamCOMPAS/COMPAS/issues/1184#issuecomment-2296981573, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGM5XNW4X4R4OD2TFRLNBELZSINAVAVCNFSM6AAAAABMX44FGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWHE4DCNJXGM . You are receiving this because you were mentioned.Message ID: @.***>

lee0517-hub commented 2 months ago

Thanks for quickly resolving this issue! I'm not very familiar with GitHub, so could you please let me know where I can find the fix code?

jeffriley commented 2 months ago

I have opened a PR with the fix for this issue: https://github.com/TeamCOMPAS/COMPAS/pull/1186.

With the fix in place, neither of the following runs fail with a segmentation faults (both run to completion):

./compas --common-envelope-formalism TWO_STAGE --random-seed 5842 -n 1
./compas --common-envelope-formalism TWO_STAGE --random-seed 0 -n 10000

Why was this issue not seen before, or in testing? In BaseBinaryStar::CalculateMassTransferOrbit(), the following code

integrate_adaptive(controlled_stepper , ode{ p_DonorMass, p_Accretor.Mass(), p_FractionAccreted, m_Accretor->IsDegenerate() }, x, 0.0, p_DeltaMassDonor, p_DeltaMassDonor / 1000.0);

references m_Accretor->IsDegenerate() instead of p_Accretor.IsDegenerate(). If the binary had undergone a previous episode of mass transfer before calling BaseBinaryStar::ResolveCommonEnvelopeEvent() (and executing the TWO_STAGE CE formalism code), m_Accretor would have contained a pointer to one of the stars (the accreting star in the most recent episode of mass transfer), so no segmentation fault would have occurred. However, in this case, at least one of the calls to BaseBinaryStar::CalculateMassTransferOrbit() would have retrieved the IsDegenerate value from the wrong star, so the results might have been incorrect (depending upon the value of IsDegenerate).

In the case of random seed = 5842, the binary had not undergone mass transfer prior to the call to BaseBinaryStar::ResolveCommonEnvelopeEvent(), so m_Accretor had not been set (so was still a null pointer as initialised), and the segmentation fault occurs.

jeffriley commented 2 months ago

@lee0517-hub , the repaired code will be in the dev branch (v03.00.03) once PR https://github.com/TeamCOMPAS/COMPAS/pull/1186 is reviewed and merged. You can check out the PR locally before it is merged if you want to test the fix.

lee0517-hub commented 2 months ago

Great work! I tested the fix and everything is running successfully. Thanks for resolving this so quickly!