tome2-ah: pressing a wrong key in automizer config crashes the game

[Therem Harth]

Entering any unrecognized symbol in the automizer config pager crashes the game with

squeltch.c:2081: display_condition: Assertion `condition != ((void *)0)' failed.

Just FYI. This makes using the automizer a real pain... I will look into it further when I have the time.

[AnonymousHero]

There was a patch posted here:

https://gitorious.org/tome2/tome2/commit/ffbf359354333d71550f9d8e474ae3f2b9fb7e2f

(for the C++ branch.)

... but it didn't seem to fix all the issues AFAICT. Plus it's a bit of a hack .

I think it might be helpful to run Clang/GCC's ASAN against the code to see where the problems like. Stack traces would be very useful.

Generally I think the Automatizer interface has always been extremely clunky compared to Vanilla's squelch system. (Though obviously much more powerful, though I suspect almost nobody ever used all that power.) Perhaps it'd be better to just replace it with something simpler -- either plain quality-based squelch or perhaps a little DSL like Entro/Poscheng (and presumably the precursors of those). JSON is just too unwieldly to edit by hand for this kind of thing.

Unfortunately, I (as always) don't really have much time for actually properly maintaining T2, and frankly I'm not feeling all that motivated ATM.

[Therem Harth]

Sorry to bug you about it then.

I would offer to maintain T2 myself, but
a) I am a terrible programmer (c.f. my use of global vars in Neoband)
b) I have no clear idea of what T2 should be
c) I don't play it very much these days anyway

[Therem Harth]

So, addendum: this only seems to be a problem on 64-bit. 32-bit is okay... I will try to debug it on 64-bit later today.

[AnonymousHero]

So, addendum: this only seems to be a problem on 64-bit. 32-bit is okay... I will try to debug it on 64-bit later today.

Hm. That's interesting... I wonder if this is related to different headers being "compiled" in 32-bit vs. 64-bit. (There are defines which control aspects of this, see "L64".)

[Therem Harth]

Hmm, this reproducible on 32 bit as well actually, but with a lot of difficulty. It seems to require a specific nesting order of clauses.

The error printed to STDERR is always

tome: /path/to/tome2/src/squeltch.c:582: condition_and_add: Assertion `c != ((void *)0)' failed.

and the backtrace looks like

#0  0xb70d79dc in raise () from /lib/libc.so.6
#1  0xb70d91f3 in abort () from /lib/libc.so.6
#2  0xb70d0ac6 in __assert_fail_base () from /lib/libc.so.6
#3  0xb70d0b77 in __assert_fail () from /lib/libc.so.6
#4  0x080d20a0 in condition_and_add ()
#5  0x080d2127 in condition_or_add ()
#6  0x080d42c7 in add_child ()
#7  0x080d5658 in add_new_condition ()
#8  0x080d5f11 in do_cmd_automatizer ()
#9  0x0816ed2e in do_cmd_options ()
#10 0x0809c92f in process_command ()
#11 0x0809d19b in process_player ()
#12 0x0809dd12 in dungeon ()
#13 0x0809e72f in play_game ()
#14 0x081de6c8 in main ()

In this case I got it with the following rule structure:

Destroy if
- And
-- Or
--- Symbol is |
--- Symbol is /
--- Symbol is \
-- Or
--- State is <hit enter when it asks for a letter>

This will crash it every time.

Edit: as a side note, am I the only one who thinks this would be better implemented as nonbranching iptables-like chains, instead of a deeply nested hierarchy?

Edit 2: actually scratch that, I'll just look up the JSON format and write mine manually. :P

[AnonymousHero]

Hmm, this reproducible on 32 bit as well actually, but with a lot of difficulty. It seems to require a specific nesting order of clauses.

The error printed to STDERR is always

tome: /path/to/tome2/src/squeltch.c:582: condition_and_add: Assertion `c != ((void *)0)' failed.

and the backtrace looks like

#0  0xb70d79dc in raise () from /lib/libc.so.6
#1  0xb70d91f3 in abort () from /lib/libc.so.6
#2  0xb70d0ac6 in __assert_fail_base () from /lib/libc.so.6
#3  0xb70d0b77 in __assert_fail () from /lib/libc.so.6
#4  0x080d20a0 in condition_and_add ()
#5  0x080d2127 in condition_or_add ()
#6  0x080d42c7 in add_child ()
#7  0x080d5658 in add_new_condition ()
#8  0x080d5f11 in do_cmd_automatizer ()
#9  0x0816ed2e in do_cmd_options ()
#10 0x0809c92f in process_command ()
#11 0x0809d19b in process_player ()
#12 0x0809dd12 in dungeon ()
#13 0x0809e72f in play_game ()
#14 0x081de6c8 in main ()

In this case I got it with the following rule structure:

Destroy if
- And
-- Or
--- Symbol is |
--- Symbol is /
--- Symbol is \
-- Or
--- State is <hit enter when it asks for a letter>

This will crash it every time.

Hopefully I'll have time to try to reproduce this and fix it at some point... and I was just about you to file an issue only to realize that gitorious doesn't seem to support issue tracking. Guess it might be time to pick a new place to host this... For now I'll add a link to this from my ever-growing TODO list...

Edit: as a side note, am I the only one who thinks this would be better implemented as nonbranching iptables-like chains, instead of a deeply nested hierarchy?

Edit 2: actually scratch that, I'll just look up the JSON format and write mine manually. :P

Yes, that's what I was talking about with the mention of a DSL. Simple kill-by-type/family is basically all that's needed in-game IMO, and advanced users could probably be asked to learn a little specialized linear language for squelch. (I'd also like to have a char-specific automatizer files, that should remove 90% of the need for any customization.)