Random segfaults (Mon_in_field)

[1942rob]

They happens randomly as you walk around

thread 1
thread 2

[1942rob]

Found anomaly Fix'd (probably)
Burned down gas station
Random driving

Note:
0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory

[Catacstone]

This, around field.cpp::1192 (field::mon_in_field),

...
  for(std::vector<field_entry*>::iterator field_list_it = curfield.getFieldStart(); field_list_it != curfield.getFieldEnd(); ++field_list_it){
     cur = (*field_list_it);
     if(cur == NULL) continue; //shouldn't happen unless you free memory of field entries manually (hint: don't do that)
...

likes to go out of the boundaries every once in a while. When examining curfield, we find out that

(gdb) print curfield
$14 = (field &) @0x1074968c0: {
  field_list = {
    <std::_Vector_base<field_entry*,std::allocator<field_entry*> >> = {
      _M_impl = {
        <std::allocator<field_entry*>> = {
          <__gnu_cxx::new_allocator<field_entry*>> = {<No data fields>}, <No data fields>},
        members of std::_Vector_base<field_entry*,std::allocator<field_entry*> >::_Vector_impl:
        _M_start = 0x10435fcc0,
        _M_finish = 0x10435fcc0,
        _M_end_of_storage = 0x10435fcc8
      }
    }, <No data fields>},
  draw_symbol = fd_null,
  dirty = false
}

every once in a while, the rng decides to "draw a blank" when it comes to moving monsters in fields.

(gdb) print cur
$15 = (field_entry *) 0x102e9b020
(gdb) print *cur
$16 = {
  type = 48714176,
  density = 1 '\001',
  age = 272882897,
  is_alive = false
}

"Kssh.. this is ground control to cur.type: get down thank you. Kssh..."

Maybe has something to do with the fact that

(gdb) print curfield.field_list.size()
$21 = 0

[1942rob]

Wouldn't the for loop be skipped altogether if that was the case?