ToME 2 maintenance

[AnonymousHero]

BTW this is stuff related to the Straight Road (i.e. Zangband Pattern). Straight Road vaults don't even exist any more. It can probably be removed.

It can be really hard to tell if something is being used. I can't say I've ever come upon any of the non-wizard or messages in that block of code, though.

I'll consider removing that code.

Though, I'm gonna take a look at the vaults info file. I want to see if I can reintroduce Straight Road vaults.

What was the distinguishing feature of those vaults? Seems that it just enforces some sort of traversal direction/order? (Which sounds silly and annoying to me.)

[Lord Estraven]

Re pattern vaults: yes. You have to follow the Straight Road while monsters snipe at you from the sidelines.

I believe the current mechanism is that you take damage if you step off the Straight Road. Not sure how much damage, probably too much. I'll take a look at it.

(Note: in Zelazney's Amber novels, stepping of f the Pattern was instantly fatal IIRC.)

[AnonymousHero]

Just in case anyone's lurking here -- I've moved the T2 source repository to GitHub. See this post for details.

[Lord Estraven]

So, I just discovered a buffer overrun in the do_cmd_fire() routine. I believe this was triggered by
1. Firing an arrow from my inventory, the last arrow of its type
2. Hitting "n" to fire again
3. Selecting a different variety of arrow

Not sure that's exactly what happened though. In any case the game promptly imploded:

Code: Select all

/home/proteus/Projects/tome2/src/cmd2.cc:3272:31: runtime error: index 17 out of bounds for type 'short int [10]'
/home/proteus/Projects/tome2/src/cmd2.cc:3272:31: runtime error: load of address 0x000001b9f5e2 with insufficient space for an object of type 's16b'
0x000001b9f5e2: note: pointer points here
 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
              ^ 
=================================================================
==9270==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000001b9f5e2 at pc 0x000000bbb818 bp 0x7ffc0da80280 sp 0x7ffc0da80278
READ of size 2 at 0x000001b9f5e2 thread T0
    #0 0xbbb817 in do_cmd_fire() (/home/proteus/Projects/tome2/src/tome+0xbbb817)
    #1 0x6eafaa in process_command() (/home/proteus/Projects/tome2/src/tome+0x6eafaa)
    #2 0x6eec2d in process_player() (/home/proteus/Projects/tome2/src/tome+0x6eec2d)
    #3 0x6f2ee4 in dungeon() (/home/proteus/Projects/tome2/src/tome+0x6f2ee4)
    #4 0x6f6465 in play_game (/home/proteus/Projects/tome2/src/tome+0x6f6465)
    #5 0x671beb in main (/home/proteus/Projects/tome2/src/tome+0x671beb)
    #6 0x7f07a139686f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2086f)
    #7 0x6632f8 in _start (/home/proteus/Projects/tome2/src/tome+0x6632f8)

0x000001b9f5e2 is located 14 bytes to the right of global variable 'ddx' defined in '/home/proteus/Projects/tome2/src/tables.cc:55:6' (0x1b9f5c0) of size 20
0x000001b9f5e2 is located 30 bytes to the left of global variable 'ddy' defined in '/home/proteus/Projects/tome2/src/tables.cc:58:6' (0x1b9f600) of size 20
SUMMARY: AddressSanitizer: global-buffer-overflow ??:0 do_cmd_fire()
Shadow bytes around the buggy address:
  0x00008036be60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008036be70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008036be80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008036be90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008036bea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x00008036beb0: 00 00 02 f9 f9 f9 f9 f9 00 00 04 f9[f9]f9 f9 f9
  0x00008036bec0: 00 00 04 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9
  0x00008036bed0: 00 00 02 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
  0x00008036bee0: 00 00 00 00 06 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x00008036bef0: 06 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 06 f9 f9 f9
  0x00008036bf00: f9 f9 f9 f9 00 00 00 00 06 f9 f9 f9 f9 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==9270==ABORTING

I will see if I can reproduce this.

Edit: got it. My inventory looked like this:

Code: Select all

...
q) 13 Arrows of Wounding
r) A Seeker Arrow of Slay Evil
(end of inventory)
...

I hit 'f r' and a direction to fire the Seeker Arrow.

Then I hit 'n' to fire again. Item slot (r) is now empty.

The game prompts me for a selection, and I hit 'q' for the Arrows of Wounding. The game then dies.

I'll have to look at the problem code, because I'm not sure why this would cause a buffer overflow. Though, given the inventory slot going from full to empty, I suspect there's a missing check for that condition.

[AnonymousHero]

It would help of you could post the commit ID you're working with.

(As mentioned in the other thread, I probably won't have any time to do any substantial work on ToME 2.x for the next month or so, so I cannot help with any code at the moment...)

[AnonymousHero]

Actually, if this is the

Code: Select all

	tx = p_ptr->px + 99 * ddx[dir];
	ty = p_ptr->py + 99 * ddy[dir];

then the problem is likely that get_aim_dir() is doing something wrong and setting dir==17... either that or something else is overflowing on the stack (and into the "dir" local variable).

No idea why it would do that, but such is T2 code... fully of mysteries .

I suggest trying to attach a debugger and to trace through the code to see where the problem starts.

[Lord Estraven]

So FWIW, the code also stopped linking on 32-bit at some point...

Code: Select all

libgame.a(monster2.cc.o): In function `monster_check_experience(int, char)':
monster2.cc:(.text+0x856): undefined reference to `magik(long)'
monster2.cc:(.text+0xa7c): undefined reference to `magik(long)'
monster2.cc:(.text+0xbec): undefined reference to `magik(long)'
monster2.cc:(.text+0xd72): undefined reference to `magik(long)'
libgame.a(monster2.cc.o): In function `pick_ego_monster(monster_race const*)':
monster2.cc:(.text+0x2629): undefined reference to `magik(long)'
libgame.a(monster2.cc.o):monster2.cc:(.text+0x237c0): more undefined references to `magik(long)' follow
collect2: error: ld returned 1 exit status
src/CMakeFiles/harness.dir/build.make:156: recipe for target 'src/harness' failed
make[2]: *** [src/harness] Error 1
CMakeFiles/Makefile2:129: recipe for target 'src/CMakeFiles/harness.dir/all' failed
make[1]: *** [src/CMakeFiles/harness.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

I suppose one could question the value of continued 32-bit support; but a lot of mobile ARM devices are still 32-bit. A future port to e.g. Android would probably have to deal with that.

[AnonymousHero]

Can you please file issues on GitHub for regular "code issues" like this?

(Really busy with work ATM, so I can't promise I'll get to them quickly, but it's better than having them scattered about in the forums.)

EDIT: Oh, yeah 32-bit isn't exactly a priority any longer, but this one should be easy to fix. It's just a declaration using the incorrect type of int, I should think.

[Lord Estraven]

I suggest trying to attach a debugger and to trace through the code to see where the problem starts.

Just FYI, GDB is not usable against ToME at the moment, at least on Debian Stable. C++11 name mangling causes GDB to segfault immediately on loading symbols. (Seriously, WTH?!)

Edit: it strikes me the above might also be on 32-bit only. Wouldn't surprise me at all, actually.

[AnonymousHero]

I suggest trying to attach a debugger and to trace through the code to see where the problem starts.

Just FYI, GDB is not usable against ToME at the moment, at least on Debian Stable. C++11 name mangling causes GDB to segfault immediately on loading symbols. (Seriously, WTH?!)

Edit: it strikes me the above might also be on 32-bit only. Wouldn't surprise me at all, actually.

Yeah, so that's a bug you should probably file with Debian .

[AnonymousHero]

Just a little HEADS UP: I've changed the build such that it produces multiple executables (one per platform) instead of the weird multiple-platforms-in-one-thing which required strange command-line contortions to give options to the game/platform.

This is basically preparation to maybe try to ressurrect the Qt port, but to do it in a less disruptive manner.

EDIT: Btw, if anyone's on a Windows machine, I'd love to hear if the build still works. (I know, I should probably find a VM or something, but frankly the number of people who care about T2 generally is small enough that I don't care enough to try that.)

[Lord Estraven]

Yeah, so that's a bug you should probably file with Debian .

So from Googling, it looks llike this has already been reported. It also won't be fixed in Stable, since policy is to only backport security fixes, IIRC.

A Qt interface sounds great on Linux, but keep in mind that the SDK for Windows is an 800+ MB download. Development on Windows is already very painful from what I've seen; though then again, so is everything else on Windows.

I'll probably spin up a WinXP VM and try building on it at some point, since I have another Windows project. Hopefully XP will suit these purposes, because a Win7 VM without VT-x runs like a drunk sloth.

[AnonymousHero]

Yeah, so that's a bug you should probably file with Debian .

So from Googling, it looks llike this has already been reported. It also won't be fixed in Stable, since policy is to only backport security fixes, IIRC.

A Qt interface sounds great on Linux, but keep in mind that the SDK for Windows is an 800+ MB download. Development on Windows is already very painful from what I've seen; though then again, so is everything else on Windows.

Ouch... 800MB is pretty steep.

I'm actually not necessarily committed to Qt, but I tried a few platform-agnostic frameworks and it seemed that it was the best-performing. (But my naive implementation wasn't actually fast enough, so...)

I might try SDL 2.x again, because AFAIR they released a huge update semi-recently.

I'll probably spin up a WinXP VM and try building on it at some point, since I have another Windows project. Hopefully XP will suit these purposes, because a Win7 VM without VT-x runs like a drunk sloth.

It would be great if you could try building and reporting back.

[Lord Estraven]

So yeah, right off the bat I can tell this will be nasty on XP. Or probably on any Windows.

- Boost doesn't have binaries built with MinGW
- The binaries compatible with XP are for an older Visual Studio version that isn't available any more
- In any case, we don't have a build configuration for any MSVC version

The most sensible method would probably be to compile Boost myself, which I am totally not going to try without VT-x. Wait - unless the headers are all that's needed at the moment? That might make it doable.

In any case, XP is a poor substitute for an actual Windows 7 build environment. (As I discovered with my other project, which has bugs manifesting at runtime on Win7 but not on XP.)

Oh, BTW: if you're feeling masochistic and want to deal with Windows yourself at any point, Microsoft offers disposable VMs for browser testing, which is what I've been using:

https://dev.windows.com/en-us/microsoft ... vms/linux/

You will (obviously) need an abundance of bandwidth for this.

[Lord Estraven]

So just a heads up, Clang and GCC support for C++14 are both really iffy on Ubuntu 14.04 LTS, and probably also on Debian Stable. I'm guessing there are a lot of people using LTS as their main desktop; seeing as Canonical loves to break things all the time in non-LTS versions...

Anyway, from what I've read on the subject, there are subtle incompatibilities between C++11 and C++14. As such I'm not sure it's a good idea to move fully to C++14 right now. Personally, I would probably want to hold off until the next LTS version of Ubuntu.

That said, I'm not the C++ programmer here. YMMV.

Edit: on a side note, I've been reading Effective Modern C++, and it's almost enough to put me off C++ completely! It seems as though C++11/14 features introduce many, many new possibilities for undefined behavior at runtime, which can be difficult to detect while writing and compiling code.