Arrays of pointers to abstract classes (sometimes) cause segfault in VariableServer when accessing std::string class members

[M-Herr]

If you allocate an array with an abstract class, the Memory Manager will allocate the memory like this:

address = calloc( (size_t)n_elems, (size_t)size
(Line 146 in MemoryManager_declare_var.cpp)

The memory is then returned to the caller uninitialized. That is all fine. The issue present itself when someone tries to access uninitialized elements of the array through the trick variable server.

For example, in EventManager::add_to_active_events(Trick::Event * in_event) if the number of active events is 1 trick will allocate an initial array with active_events = (Trick::Event **)TMM_declare_var_s("Trick::Event* [100]");. The Event Manager then assigns the new event to the correct index and returns. If the event is store at index 1, and you try to access the 'name' variable in Trick::Event at index 2 - the sim crashes (segfault).

Line 327 in VariableReference.cpp

 // handle c++ string and char*
    if ( _trick_type == TRICK_STRING ) {
        if (_address == NULL) {
            _size = 0 ;
        } else {
            _size = strlen((char*)_address) + 1 ; <----Crash happens here
        }
    }

Possible solution:

I haven't tested this extensively, but here's an excerpt from the add_to_active_events function:

if (num_active_events == 1) {
        active_events = (Trick::Event **)TMM_declare_var_s("Trick::Event* [100]");
        num_allocated = 100 ;
    } else if ( num_active_events >= num_allocated ) {
        num_allocated += 100 ;
        active_events = (Trick::Event **)TMM_resize_array_1d_a(active_events, num_allocated);
        for ( unsigned int ii = num_active_events ; ii < num_allocated ; ii++ ) {
            active_events[ii] = NULL ;
        }
    }

Setting uninitialized memory to null outside of the if statements seems to fix the crash.

if (num_active_events == 1) {
        active_events = (Trick::Event **)TMM_declare_var_s("Trick::Event* [100]");
        num_allocated = 100 ;
    } else if ( num_active_events >= num_allocated ) {
        num_allocated += 100 ;
        active_events = (Trick::Event **)TMM_resize_array_1d_a(active_events, num_allocated);
    }

  for ( unsigned int ii = num_active_events ; ii < num_allocated ; ii++ ) {
            active_events[ii] = NULL ;
        }

I don't know if this is the "right" solution, but thought I'd include it as it at least stops the crash from happening.

Fun and interesting behaviors

1. Crash only happens with std::string, other types resolve to their interpretation of whatever happens to be in their uninitialized memory.
2. Crash does not happen if num_active_events == 0 (so no memory allocated for this array by the TMM)
3. After the crash, if you restart the sim and try to look at the Trick Event names again...it works. No crash.
4. Make clean and try again - crash.

Steps to reproduce:

1. Add the following event to RUN_test/input.py in SIM_cannon_numeric

test_event = trick.new_event("TestEvent")
test_event.condition(0, "trick.exec_get_sim_time() > 1.0")
test_event.action(0, """print("Hello there!)""")
test_event.condition_all()
test_event.set_cycle(1.0)
test_event.activate()
trick.add_event(test_event)

2. Run the sim
3. Open Trick TV and access trick_em.em.active_events[0][0][0][5]

The last one is a little strange as well. Sometimes it works. From some experimenting, if the garbage in memory happens to translate to an empty string everything works okay. But if it doesn't, then the segmentation fault occurs.

[hchen99]

@M-Herr Thank you for the thorough information and for demonstrating the test. We’ll be looking into this further.

[excaliburtb]

fake news!

[excaliburtb]

j/k lol

[hchen99]

j/k lol

I do remember you brought up a similar issue before, lol

[excaliburtb]

the issue i ran into that i believe could be the root of the problem is that the resize call ends up doing a memcpy which doesn't work for std::string's because the original string instance will deallocate the underlying char * when it is destroyed.

[hchen99]

That sounds very reasonable. However, when the first event is added, the resize function isn't called, and memory is allocated for 100 events right away. The resize function won't be triggered until 100 events have been added. I recall this issue was there when testing with just a single event. I may have misunderstood your point though. Will test a bit more. Thanks!

[excaliburtb]

also, that event allocation example is for allocating an array of pointers to events. not the events themselves. so something else is happening for the event case i would think

[hchen99]

Was wondering about the same thing and did try to make event object with str initialized as empty string. The issue seemed still there. But I did it very quick and never got back to it. Could be that the test wasn't done properly