Crash on game load #15628

Maeyanie · 2016-03-01T14:01:45Z

Orginally found on version cb34c3a, but continued after I reverted to 6dad07e.

Not sure what the cause of this one is, haven't been able to figure out much of anything, even what causes this type of error. But, I have a savegame which crashes on load (or sometimes after 1 step) with the following:

/usr/include/c++/5.3.1/debug/safe_iterator.h:182:error: attempt to copy-
    construct an iterator from a singular iterator.

Objects involved in the operation:
iterator "this" @ 0x0xf184708 {
type = N11__gnu_debug14_Safe_iteratorINSt9__cxx199814_List_iteratorI4itemEENSt7__debug4listIS3_SaIS3_EEEEE (mutable iterator);
  state = singular;
}
iterator "other" @ 0x0xf1f7f38 {
type = N11__gnu_debug14_Safe_iteratorINSt9__cxx199814_List_iteratorI4itemEENSt7__debug4listIS3_SaIS3_EEEEE (mutable iterator);
  state = singular;
  references sequence with type `NSt7__debug4listI4itemSaIS1_EEE' @ 0x0xb5704c0
}

Program received signal SIGABRT, Aborted.
(gdb) bt
#0  0x00007ffff61dca98 in raise () from /lib64/libc.so.6
#1  0x00007ffff61de69a in abort () from /lib64/libc.so.6
#2  0x00007ffff6b38185 in __gnu_debug::_Error_formatter::_M_error() const ()
   from /lib64/libstdc++.so.6
#3  0x0000000000ca71a7 in __gnu_debug::_Safe_iterator<std::__cxx1998::_List_iterator<item>, std::__debug::list<item, std::allocator<item> > >::_Safe_iterator (__x=..., this=0xf184708)
    at /usr/include/c++/5.3.1/debug/safe_iterator.h:178
#4  item_reference::item_reference (this=0xf1846f0) at src/active_item_cache.h:11
#5  std::__cxx1998::_List_node<item_reference>::_List_node<item_reference const&> (this=0xf1846e0)
    at /usr/include/c++/5.3.1/bits/stl_list.h:114
#6  __gnu_cxx::new_allocator<std::__cxx1998::_List_node<item_reference> >::construct<std::__cxx1998::_List_node<item_reference>, item_reference const&> (__p=0xf1846e0, this=<optimized out>)
    at /usr/include/c++/5.3.1/ext/new_allocator.h:120
#7  std::__cxx1998::__cxx11::list<item_reference, std::allocator<item_reference> >::_M_create_node<item_reference const&> (this=0x7fffffffcd58) at /usr/include/c++/5.3.1/bits/stl_list.h:574
#8  std::__cxx1998::__cxx11::list<item_reference, std::allocator<item_reference> >::_M_insert<item_reference const&> (__position=..., this=0x7fffffffcd58)
    at /usr/include/c++/5.3.1/bits/stl_list.h:1763
#9  std::__cxx1998::__cxx11::list<item_reference, std::allocator<item_reference> >::push_back (
    __x=..., this=0x7fffffffcd58) at /usr/include/c++/5.3.1/bits/stl_list.h:1089
#10 active_item_cache::get (this=<optimized out>) at src/active_item_cache.cpp:43
#11 0x00000000009d3522 in map::process_items_in_vehicle<bool (*)(item_stack&, __gnu_debug::_Safe_iterator<std::__cxx1998::_List_iterator<item>, std::__debug::list<item, std::allocator<item> > >&, tripoint const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)> (
    this=this@entry=0xb192170, cur_veh=0xb4ce990, current_submap=current_submap@entry=0xb4c3270,
    processor=processor@entry=0x9a3477 <process_map_items(item_stack&, std::__debug::list<item, std::allocator<item> >::iterator&, tripoint const&, std::__cxx11::string)>, signal="")
    at src/map.cpp:4894
#12 0x00000000009d4bcb in map::process_items_in_vehicles<bool (*)(item_stack&, __gnu_debug::_Safe_iterator<std::__cxx1998::_List_iterator<item>, std::__debug::list<item, std::allocator<item> > >&, tripoint const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)> (
    this=this@entry=0xb192170, current_submap=current_submap@entry=0xb4c3270,
    processor=processor@entry=0x9a3477 <process_map_items(item_stack&, std::__debug::list<item, std::allocator<item> >::iterator&, tripoint const&, std::__cxx11::string)>, signal="")
    at src/map.cpp:4881
#13 0x00000000009d4e44 in map::process_items<bool (*)(item_stack&, __gnu_debug::_Safe_iterator<std::__cxx1998::_List_iterator<item>, std::__debug::list<item, std::allocator<item> > >&, tripoint const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)> (
    this=0xb192170, active=active@entry=true,
    processor=processor@entry=0x9a3477 <process_map_items(item_stack&, std::__debug::list<item, std::allocator<item> >::iterator&, tripoint const&, std::__cxx11::string)>, signal="")
    at src/map.cpp:4833
#14 0x00000000009b62d8 in map::process_active_items (this=<optimized out>) at src/map.cpp:4815
#15 0x0000000000769e1c in game::do_turn (this=0xb22aae0) at src/game.cpp:1457
#16 0x0000000000a5f6e7 in main (argc=0, argv=0x7fffffffe150) at src/main.cpp:434
(gdb)

If posting the savegame would help, please let me know.

The text was updated successfully, but these errors were encountered:

codemime · 2016-03-07T23:19:46Z

Yes, it would be helpful. Please post it.

Maeyanie · 2016-03-09T02:34:47Z

I had originally not included this because the save directory was fairly large, but I forgot how well JSON compresses. :)

https://www.dropbox.com/s/jeysste12k6s16a/Lakeshire.7z

When reproducing, please note that the crash only happens on a debug build, as that checking isn't done on a release compile.

codemime · 2016-03-10T01:14:24Z

I couldn't reproduce it on 60561b6. However, your save requires the "Arts' Guns" mod which I don't have. Maybe it's somehow responsible for the crash. But I could get a (probably different) segfault on the starting screen when I tried to build without lua support. It was certainly caused by the missing mod and I'm going to fix it.

mugling · 2016-03-10T01:16:06Z

However, your save requires the "Arts' Guns" mod

...which has had some recent compatibility problems with master?

codemime · 2016-03-10T01:22:19Z

Didn't know about that (actually, I haven't even heard about that mod before).

Maeyanie · 2016-03-10T01:25:16Z

It could be related to that mod, I suppose, though being a JSON-only mod if it causes a crash there's still a bug hiding somewhere. It's unfortunately (or fortunately, depending on how you look at it) not a problem I can easily reproduce.

mugling · 2016-03-10T01:31:30Z

I'm not especially familiar with that mod - didn't it include a source patch or am I mistaken? If its pure JSON it's either unrelated or as you say master is bugged

bdragon28 · 2016-03-10T03:35:06Z

This crashdump is ringing a vauge bell for me. Rotting items in the cargo were crashing with a similar backtrace because of some bugs in the debug containers stl support shipped with debian wheezy (libstdc++ 4.7.2).

Looking at your library paths I'm guessing you're on... Fedora 23? Perhaps there is a similar issue with the debugging containers on your compiler. Does it still crash if you compile it on a different machine?

Also, I'm going to predict that even with that compiler, it probably won't crash if you do a release build.

bdragon28 · 2016-03-10T03:39:21Z

Ah, you already said as much re: it working ok in release mode.
See also: #11108 #12743

bdragon28 · 2016-03-10T04:42:34Z

I spent a bit of time comparing the header on the three platforms. (4.7.2 era, 4.9.2 era, and 5.3 era)

The debug check in question goes way back to DR 408 @ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15523 and seems to be slightly different on all 3 (the only difference between 4.7.2 and 4.9.2 era is the addition of _GLIBCXX_NOEXCEPT. 5.3 has some changes that were done to work around some race condition in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 )

I am not near skilled enough in c++ to determine if it's the libstdc++ debug checks that are wrong or active_item_cache that is wrong.

Maeyanie · 2016-03-10T07:34:56Z

I'm not sure if Artyom's used a source patch in the past, but it certainly doesn't now.

Yeah, that stack trace is from Fedora 23. I also got an essentially-identical crash in Windows when compiling under mingw64 (msys2). That seems to be using GCC 5.3.0, so not much different from the 5.3.1 in F23. Unfortunately I don't have any more-different platforms handy, at least which are able to compile a functioning CDDA.

bdragon28 · 2016-03-11T16:40:43Z

The more I look at this, the more I think that the check is legit and active_item_cache is depending on undefined behavior. I think that map::process_items_in_vehicle's blind iteration on cur_veh->active_items.get() might be problematic when some items are deleteing themselves during processing.

The confusing bit is where it only seems to crash on certain compiler versions. Maybe this is dependent on some implementation details inside the compiler. Or maybe the 4.9.2 era header doesn't trigger the debug properly somehow.

I brought up a FC23 vm and was able to reproduce some of the other cases of this crash. The save posted in #14381 for example is back to crashing on FC23 (press | and wait 30 minutes)

Coolthulhu · 2016-03-11T16:52:47Z

Items deleting themselves? That would be bad practice and should probably be reported as a bug by itself too.

Could it be related to explosions? Explosions can damage and destroy surrounding items, which could invalidate the existing iterator.

bdragon28 · 2016-03-11T16:54:12Z

No, it's items rotting away.

bdragon28 · 2016-03-11T16:58:08Z

specifically, as far as I can tell it's items rotting away while process_items_in_vehicle is looping over the active items. I am only assuming that this is what happens, can't prove it yet. SOMETHING is screwing up an iterator somewhere in there though.

mlangsdorf · 2018-10-03T11:55:56Z

Duplicated in #25934 which has a better reproducer.

mugling added the <Crash / Freeze> Fatal bug that results in hangs or crashes. label Mar 7, 2016

codemime mentioned this issue Mar 11, 2016

Fix a crash on load with a non-existing mod #15750

Merged

bdragon28 mentioned this issue Mar 12, 2016

[CR] Debug build crash fix in active item lists #15764

Closed

narc0tiq mentioned this issue Mar 19, 2016

Saved game results in crash after a certain amount of time #15830

Closed

BevapDin mentioned this issue Jun 25, 2016

Fix crash in active_item_cache #17364

Merged

Coolthulhu closed this as completed in #17364 Jun 26, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Crash on game load #15628

Crash on game load #15628

Maeyanie commented Mar 1, 2016

codemime commented Mar 7, 2016

Maeyanie commented Mar 9, 2016

codemime commented Mar 10, 2016

mugling commented Mar 10, 2016

codemime commented Mar 10, 2016

Maeyanie commented Mar 10, 2016

mugling commented Mar 10, 2016

bdragon28 commented Mar 10, 2016

bdragon28 commented Mar 10, 2016

bdragon28 commented Mar 10, 2016

Maeyanie commented Mar 10, 2016

bdragon28 commented Mar 11, 2016

Coolthulhu commented Mar 11, 2016

bdragon28 commented Mar 11, 2016

bdragon28 commented Mar 11, 2016

mlangsdorf commented Oct 3, 2018

Crash on game load #15628

Crash on game load #15628

Comments

Maeyanie commented Mar 1, 2016

codemime commented Mar 7, 2016

Maeyanie commented Mar 9, 2016

codemime commented Mar 10, 2016

mugling commented Mar 10, 2016

codemime commented Mar 10, 2016

Maeyanie commented Mar 10, 2016

mugling commented Mar 10, 2016

bdragon28 commented Mar 10, 2016

bdragon28 commented Mar 10, 2016

bdragon28 commented Mar 10, 2016

Maeyanie commented Mar 10, 2016

bdragon28 commented Mar 11, 2016

Coolthulhu commented Mar 11, 2016

bdragon28 commented Mar 11, 2016

bdragon28 commented Mar 11, 2016

mlangsdorf commented Oct 3, 2018