So, um, I got a vehicle crash while I was crashing vehicles...

[narc0tiq]

Core was generated by `./cataclysm'.
Program terminated with signal 11, Segmentation fault.
#0  0x08696ffc in map::is_bashable (this=0xf70eb0ec, x=-6, y=76) at src/map.cpp:1343
1343        if (veh_in_active_range && veh_exists_at[x][y]) {
(gdb) bt
#0  0x08696ffc in map::is_bashable (this=0xf70eb0ec, x=-6, y=76) at src/map.cpp:1343
#1  0x0869893b in map::bash_rating (this=0xf70eb0ec, str=6, x=-6, y=76) at src/map.cpp:1408
#2  0x088e08c5 in monster::move (this=0xbc42a90) at src/monmove.cpp:354
#3  0x08363142 in game::monmove (this=0xf70eb008) at src/game.cpp:6311
#4  0x0835a703 in game::do_turn (this=0xf70eb008) at src/game.cpp:1423
#5  0x086738ba in main (argc=0, argv=0xff8d5fd8) at src/main.cpp:294
(gdb) print veh_in_active_range
$1 = true
(gdb) print veh_exists_at[x][y]
Cannot access memory at address 0xf70eae8c

I'm confused. What's the real intended usage here, 'cause accessing negative array indices is clearly a bad idea?

[kevingranade]

AFAIK nothing but global overmap coordinates uses negative numbers, so I'm
guessing that monster::move() is going crazy and using bad coordinates.

[BevapDin]

All map functions should probably check the coordinates with map::inbounds. Negative or otherwise out-of-bounds coordinates are possible, for example when the surroundings of a given point get checked.

Otherwise the caller of the those map-functions needs to check for out-of-bounds and that is very impractical.

[heema]

don't know if its related, but when ever i examine the part of the vehicle that contains the fuel tank the game crashes

[CIB]

Yes, negative coordinates are bad. I've had plenty of those while debugging map3d.

It seems to me the monster had a target location that got shifted out of the reality bubble. There doesn't seem to be any check for that.

void monster::shift(int sx, int sy)
{
    _posx -= sx * SEEX;
    _posy -= sy * SEEY;
    for (auto &i : plans) {
        i.x -= sx * SEEX;
        i.y -= sy * SEEY;
    }
}

Which is weird, I mean in theory you should have squirrels with target destinations outside the reality bubble all the time? I might've missed something.

[IFailAtGaming]

Heema, it's probably unrelated, but i've got a similar problem with any kind of tank if it reaches a certain level( water was 81% and fuel was 90 something but it only seems to happen on my RV

[narc0tiq]

@heema @IFailAtGaming

when ever i examine the part of the vehicle that contains the fuel tank the game crashes

Yeah, that'll be the bug I fixed in #9081 that got into Jenkins build 2113. Try updating. Also, definitely not related to this.

[unikmhz]

Similar crash happened here. Git master of couple minutes ago, 64-bit, GCC 4.8.3. Here's the frame and full backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000805d7d in map::is_bashable (this=0x7ffff7f951a8, x=-17, y=80) at src/map.cpp:1343
1343        if (veh_in_active_range && veh_exists_at[x][y]) {
#0  0x0000000000805d7d in map::is_bashable (this=0x7ffff7f951a8, x=-17, y=80) at src/map.cpp:1343
No locals.
#1  0x0000000000806348 in map::bash_rating (this=0x7ffff7f951a8, str=16, x=-17, y=80) at src/map.cpp:1408
        furn_smash = false
        ter_smash = false
        bash_min = 43627976
        bash_max = 0
#2  0x0000000000562671 in npc::go_to_destination (this=0x29aeea0) at src/npcmove.cpp:2225
        dy = 0
        dx = 0
        i = 0
        x = -17
        y = 80
        linet = 32767
        light = 1
        omt_pos = {x = 155, y = 59, z = 0}
        sx = -1
        sy = 1
#3  0x0000000000555386 in npc::execute_action (this=0x29aeea0, action=npc_goto_destination, target=-1) at src/npcmove.cpp:389
        tary = 72
        line = std::__debug::vector of length 0, capacity 0
        oldmoves = 100
        tarx = -9
        linet = -1
        light = 1
#4  0x0000000000554368 in npc::move (this=0x29aeea0) at src/npcmove.cpp:146
        action = npc_goto_destination
        total_danger = 0
        danger = 0
        target = -1
        vehicle = 0
#5  0x00000000008e305a in game::monmove (this=0x7ffff7f95010) at src/game.cpp:6354
        moves = 100
        turns = 0
        it =
        friendlies = std::__debug::vector of length 0, capacity 0
#6  0x00000000008bddee in game::do_turn (this=0x7ffff7f95010) at src/game.cpp:1423
No locals.
#7  0x000000000097f000 in main (argc=0, argv=0x7fffffffd090) at src/main.cpp:294
        check_all_mods = false
        saved_argv = 0x7fffffffd090
        seed = 1411140582
        verifyexit = false
        saved_argc = 0
        sigIntHandler = {__sigaction_handler = {sa_handler = 0x97f862 <exit_handler(int)>, sa_sigaction = 0x97f862 <exit_handler(int)>}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0xd62ae0 <__libc_csu_init>}
        quit_game = false

[CIB]

Uhm this bug isn't really fixed, it's more like the warning was silenced.

[narc0tiq]

No, checking map::inbounds makes sure this crash never happens -- which is to say, calling is_bashable on an out-of-bounds tile will just return false; (and log a warning). This fixes the bug, period.

That said, there may be other map::stuff() that will react similarly.