Segfault when stepping onto same tile as Shopping Cart

[iwearsable]

I've been experiencing segfaults on very recent versions of experimental, compiled myself. Usually happens when stepping onto the same tile as a shopping cart loaded up with many items. Does not happen all of the time (varied intermittent frequency) but I could probably reproduce it in a given evening.

I have a few different stack traces saved but they all look similar to the one below. Please let me know if it would be useful to post the others, or I could even reproduce the error and run some other specific commands in GDB if that was wanted and specific instructions were given to me.

Thread 1 "cataclysm-tiles" received signal SIGSEGV, Segmentation fault. 0x00007ffff6d91256 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (gdb) bt #0 0x00007ffff6d91256 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x0000000000435bbe in std::operator< <char, std::char_traits<char>, std::allocator<char> > ( __lhs=<error reading variable: Cannot access memory at address 0x500000027>, __rhs="REACTOR") at /usr/include/c++/5/bits/basic_string.h:4989 #2 0x0000000000488bf4 in std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::operator() (this=<optimized out>, __y="REACTOR", __x=...) at /usr/include/c++/5/bits/stl_function.h:387 #3 std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::_Identity<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_lower_bound (this=<optimized out>, __k="REACTOR", __y=0x1c71bc88, __x=<optimized out>) at /usr/include/c++/5/bits/stl_tree.h:1644 #4 std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::_Identity<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::less<std::__cxx11::basic_string<char,---Type <return> to continue, or q <return> to quit--- std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::find ( __k="REACTOR", this=0x1c71bc80) at /usr/include/c++/5/bits/stl_tree.h:2308 #5 std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::count (this=0x1c71bc80, __x="REACTOR") at /usr/include/c++/5/bits/stl_set.h:668 #6 0x00000000005c88d1 in vpart_info::has_flag (this=<optimized out>, flag="REACTOR") at src/veh_type.h:208 #7 0x0000000000735238 in vehicle_part::is_reactor (this=this@entry= 0xe38fc0 <vehicle::current_engine()::null_part>) at src/vehicle.cpp:6037 #8 0x0000000000735326 in vehicle_part::ammo_current[abi:cxx11]() const ( this=this@entry=0xe38fc0 <vehicle::current_engine()::null_part>) at src/vehicle.cpp:5743 #9 0x00000000007d2570 in player::disp_status (this=0x17e7be70, w=0xd0b2500, w2=<optimized out>) at src/player.cpp:3642 #10 0x00000000006b4315 in game::draw_sidebar (this=this@entry=0x12845f40) at src/game.cpp:4866 #11 0x00000000006b509e in game::draw (this=this@entry=0x12845f40) at src/game.cpp:4830 #12 0x00000000006de79e in game::do_turn (this=0x12845f40) at src/game.cpp:1543 #13 0x000000000041d718 in main (argc=<optimized out>, argv=<optimized out>) ---Type <return> to continue, or q <return> to quit--- at src/main.cpp:491

[iwearsable]

Here's a file with three segfaults because it seemed to make it nearly unreadable above

segfaults.txt

[hmstanley]

Happened to me too.. However, it happened when i was in a grocery store, with the cart in my 6 position and the glass doors to the refrigeration units in front of me..I "G" the cart to get around the cart, and it crashed. Note, when I normally using the cart in my den or other places, and enter the same tile, not crashes.

[codemime]

This can be related to #19168.

[iwearsable]

@hmstanley, yeah I've had it happen in my home base as well, or even out in the open. It's possible I've had it happen without even stepping onto the cart itself, but the one example of that I experienced happened when near a cart (or maybe dragging it without stepping on it) but that was before I compiled with symbols to be able to see if it was for sure related. The three traces I have in the text file above all seem to be related as far as my limited ability can tell and all were caused when stepping onto a cart with items in its inventory. I do suspect there may be other possible situations that can cause it (other than stepping on a cart), but I don't know for sure.

For awhile there I had three shopping carts in my base holding items and it was out of control with segfaults. That was before I compiled with symbols, and I've long since moved the carts out of my base and only use them on raids.

[hurston1]

It does the same with the wheelbarrow

[remyroy]

Do you have a save file that can reliably and easy reproduce this problem with the latest experimental version? If you do, please upload it somewhere and link it here. Please provide the steps from loading that save that will cause this issue. That would be quite useful for debugging and eventually solving it. Thanks.

[hurston1]

It can't be reliably produced, but it is not uncommon. If you load a particular save file, sometimes it will crash when moving over a shopping cart, sometimes it wont. To reproduce it, I suggest a cycle of load game, move over shopping cart and save game until it fails, which shouldn't take long.

[remyroy]

I'm currently debugging this issue and it feels like some memory corruption error. In some cases, the code would end up in an infinite loop trying to use the count method on std::set<std::string> flags on a vpart_info. In other cases it would just segfault. It is quite unpredictable and it sometimes takes a few random number of tries which would tend to confirm the memory corruption theory.

Let me see if I can find the source of this issue.

[remyroy]

After a nice bisect session, it seems like this issue was introduced with bcafb09 by @mugling . I'm adding him to this discussion in case he has some insight to provide.

I'll keep investigating.

[remyroy]

The info_cache value of the static vehicle_part null_part in vehicle_part &vehicle::current_engine is being overwritten when you save/reload a game without ending game process. It corrupts the memory of that member.

I'm still trying to find the source of this issue.

[iwearsable]

@Remroy

I'll try to reproduce it and upload a save if I can. But it's flaky about whether or not it wants to do it a lot or a little. Actually, I'll try to go back to savescum save I have

[iwearsable]

Here's an old save I have. I tried to reproduce bug without saving and reloading (trying to learn the midgame, I savescum incessantly on this playthrough. lol).

I could not reproduce it without saving and then loading again. As soon as I did so (save and reload) and stepped on the cart, crash... (actually I moved around with the cart a bit before saving, should mention that in case it can't be reproduced simply by opening saving and opening again then moving onto the cart, but that would probably work)

You are on the right track there. Here's a save if it is needed
Tucky.tar.gz

Thank you! I understand now a bit more about this

[remyroy]

The source of this issue was already found and a fix for it has been completed in #19790. It might be included soon.

[remyroy]

Someone else is gonna have to fix it.

[hurston1]

Thanks for taking the time to look at this remyroy, much appreciated

[kevingranade]

Based on remyroy finding the issue and a suggestion by codemime, I'm looking into creating a fix based on initializing the pointer in question with another static object for null parts. It's a little more involved since I'm updating the type involved to not allow its id field to be edited, since that would break the caching here.

[iwearsable]

Thank you all!