amusecode / seba Goto Github PK

I believe there is a bug in the SeBa interface when using the function recall_memory_one_step.
The interface uses a parameter called seba_time. Every timestep this parameter is updated to the end_time (see the function evolve_system in interface.cc). However, when recall_memory_one_step is called it is not reset. As a result I'm running into the situation that after the recall, when the new needed timestep is calculated in evolve_system, the timestep is negative. Consequently SeBa keeps on running as the end_time is never reached (while loop is never broken).

Suggested solution: I suggest we set the seba_time to the current_time at the end of the recall_memory_one_step function, e.g.:
seba_time = seba_node->get_starbase()->get_current_time() - seba_node->get_starbase()->get_time_offset();

I was trying to compile it

When running the code with the option -U Power_Law, the output file SeBa.data contains -nan in place of the separation and the eccentricity (columns 5 and 6).
It could be caused by a bug at line 560 of initdouble.c
I believe it could be fixed by changing
ecc = get_random_eccentricity(e_min, e_max, ef, m_prim+m_sec);
to
ecc = get_random_eccentricity(e_min, e_max, ef, e_exp);

The Makefiles of SeBa include the optimisation flag -O through CFLAGS += -O
However CFLAGS is not used.

My suggestion: add a flag: CXXFLAGS += -O (or -O2)

Any objections of why not to do this?

In file initdouble.c, lines 165-186:

char* type_string(mass_ratio_distribution qf) {

    local char  qf_name[SEED_STRING_LENGTH];
    switch(qf) {
       case Equal_q:
            sprintf(qf_name, "Equal_q"); 
        break;	    
       case Flat_q:
            sprintf(qf_name, "Flat_q"); 
        break;	    
       case qf_Power_Law:
            sprintf(qf_name, "Power_Law"); 
        break;	    
       case Thermal_Distribution:
            sprintf(qf_name, "Hogeveen"); 
        break;	    
       default:
            sprintf(qf_name, "Unknown_qf"); 
        break;
    }
    return qf_name;
}

I believe that line 178 should be case Hogeveen instead of case Thermal_Distribution, because Thermal distribution is a type of eccentricity distribution, not mass ratio.

As of now, this does not create problems, because Thermal_Distribution and Hogeveen are both equal to 3. But if the issue Wrong values of the eccentricity distribution -u parameter #14 is resolved in the way I suggested, then Thermal_Distribution would become 2, and this would break the code.

The documentation says:

-U/u eccentricity option:
.0) Equal eccentricity
.1) Power Law
.2) Thermal distribution [default] Option -U requires one of the following strings:
(Equal_ecc, ecc_Power_Law, Thermal_Distribution) -u requires appropriate interger (see double_star.h)

But what really happens when setting the value of u is:

.0) Unknown_eccf
.1) Equal_ecc
.2) ecc_Power_Law
.3) Thermal_Distribution

I believe it could be fixed by setting Unknown_eccf=-1 at line 190 of starbase.h

The documentation says that the parameter -U needs one of the following strings to be passed:

Equal_ecc, ecc_Power_Law, Thermal_Distribution

Actually, the code only accepts one of the following strings:

Equal_ecc, Unknown_eccf, Power_Law

Therefore, to set a power law distribution, one needs to write -U Power_Law, not -U ecc_Power_Law, as indicated in the documentation. Furthermore, it is currently impossible to set a thermal distribution using the -U parameter.

Reference: extract_eccentricity_distribution_type_string function in initdouble.C

The paramlog string is set to contain 90 characters (line 261). But the formatting string on line 353 is about 120 characters long; well over those 90 characters. This can cause a buffer overflow.

Previous versions didn't have the CT_method section of the formatting string, making it shorter (possibly just about 90 characters, depending on the floating point values having 1 or multiple digits on the left side of the decimal dot), so the problem will likely not have shown. This part of the string was introduced in a recent commit, bbd9187.

In addition, certainly in non-optimised compiled code, strings often have some leeway that they can run over their allocated buffer (unintentionally, and basically undefined behaviour), so this may also cause some people to not have come across this error yet (for example, clang 15 on macOS happily runs SeBa, while gcc 11 on Ubuntu 22.04 will throw a buffer overflow error).

One fix is to increase the buffer size, to e.g. 150. In addition, it might be good to use snprintf instead of sprintf, which makes its intention clearer to a future programmer that extends the formatting string. Given that this is C++ code, it may also be useful to use std::string instead, but that probably requires a C++11 flag for the compiler and restructuring more code.

Note that seedlog does not have (yet) this problem, eyeballing the length of the formatting string in line 376.

Here's the actual error (gcc 11 on Ubuntu 22.04):

$ ./SeBa -M 2 -m 1 -e 0.2 -a 200 -T 13500 -z 0.001
random number generator seed = 1714574797
*** buffer overflow detected ***: terminated
zsh: IOT instruction (core dumped)  ./SeBa -M 2 -m 1 -e 0.2 -a 200 -T 13500 -z 0.001