Xygos 0.0.2 "Chuckie Egg" released

[backwardsEric]

Not sure if this is the appropriate thread for a bug report about Xygos, but here's one

OS: macOS 10.15.7; Xcode 12.4 for the compiler; built from source (commit number 49cbe9eff8e17b20fe1bd8912f73675233b1bc62, "An easter egg ....", was HEAD) using

./autogen.sh
cd src; make -f Makefile.osx

Problem: Crashes on a segmentation fault immediately after character creation. The new character was a human, no mutations or implants, engineer, default point buy for the stats, and a randomly selected name. Took the Foraging talent from the talent selection screen. Recompiling with debugging enabled and rerunning crashed at the same point. The top of the call stack at the point of the crash for that was

cave_monster_max(c=0) at cave.c:595
monster_list_new at mon-list.c:33
monster_list_shared_instance at mon-list.c:94
monster_list_show_subwindow(height=16, width=42) at ui-mon-list.c:354
update_monlist_subwindow(type=EVENT_MONSTERLIST, data=0, user=0x000000010054c3a8) at ui-display.c:1766
game_event_dispatch(type=EVENT_MONSTERLIST, data=0) at game-event.c:43
event_signal(type=EVENT_MONSTERLIST) at game-event.c:142
redraw_stuff(p=0x00000001028eba08) at player-calcs.c:2364
ui_enter_world(type=EVENT_ENTER_WORLD, data=0, user=0) at ui-display.c:2617
game_event_dispatch(type=EVENT_ENTER_WORLD, data=0) at game-event.c:43
event_signal(type=EVENT_ENTER_WORLD) at game-event.c:142
start_game(new_game=true) at ui-game.c:420
play_game(new_game=true) at ui-game.c:440

It looks like it may be using my existing subwindow setup from Angband, and that may explain why the monster list window is being updated at the point of the crash.

[Pete Mack]

To fix this problem, edit the make file version number and executable name.

[Mike]

This is definitely the appropriate place to report Xygos bugs. This doesn't look Mac specific, and at first glance I thought that all extra windows could be affected - I don't normally play with them and so haven't really tested them. But I have been unable to reproduce it - and the flip side of not playing with extra windows is that I haven't meddled with them. So although sharing window positions etc. with V would be unintended behaviour it still seems unlikely that doing so would cause problems. It looks as if the window is trying to be displayed too early - when there is no level generated (the null cave pointer). Simply ignoring that case would probably be effective, but I would prefer to know why it happens and how to see it on Linux.



So, please could you post your .prf? The Linux equivalent is ~/.angband/Xygos/x11-settings.prf. I don't know where they are kept on MacOS.

[Mike]

While I did say that I didn't think that this was the cause of the segfault - it's still a bug, whether or not it is the same bug that caused that crash. If there's a duff version or exe name I would like to fix it. But at my first look there isn't - could you point me at the file/line you mean?

[backwardsEric]

Originally Posted by Mike

So, please could you post your .prf? The Linux equivalent is ~/.angband/Xygos/x11-settings.prf. I don't know where they are kept on MacOS.

The contents of ~/Documents/Angband/window.prf are attached as window.txt . The ~/Documents/Xygos directory (where the Mac front end would tell Xygos to place user files) doesn't have a window.prf. For Angband, the size and placement for the active subwindows are stored by the Mac front end in ~/Library/Preferences/rephial.org.angband.plist . The human-readable form of that (generated with "plutil -p file") is attached as angband-pref.txt. It says I've got subwindows 1, 2, 3, 4, and 5 open by default.

src/Makefile.osx in Xygos uses the same setting for BUNDLE_IDENTIFIER as Angband does (i.e. org.rephial.angband). That is why the Mac front-end preferences are shared. Changing that would keep them separate.

[Mike]

I've been unable to reproduce the crash on Linux, but I do now have a Mac build up that uses its own BUNDLE_IDENTIFIER and so shouldn't share any prefs with Angband. I'd appreciate it if someone could give that a try and see if it avoids the crash.

[backwardsEric]

Originally Posted by Mike

I've been unable to reproduce the crash on Linux, but I do now have a Mac build up that uses its own BUNDLE_IDENTIFIER and so shouldn't share any prefs with Angband. I'd appreciate it if someone could give that a try and see if it avoids the crash.

The change to the bundle identifier works as intended. The crash immediately after exiting the birth process (as before, segmentation fault in cave_monster_max() while displaying the monster list subwindow) still happens (wiping any previous ~/Documents/Xygos and deleting the Mac front end defaults with

defaults delete xygos.rephial.org

, to simulate startup on a system where it hadn't been run before, did not help).

Without any prior defaults, the Mac front end is always setting up default sizes and placements for Term-1 to Term-5. That behavior is in Angband as well. Those terms will open immediately after going from the splash screen to the birth process. Closing them all before leaving the birth process does not prevent the crash. Changing line 350 of src/ui-mon-list.c to

if (height < 1 || width < 1 || !cave)

did let things proceed to the town, and I didn't encounter any problems after that.

To reproduce the crash on Linux, this worked for me (using Debian Buster; compiled from the latest source after configuring

./configure --with-no-install

; the X11 developer packages were installed so the X11 interface was enabled by default):

1. Run ./xygos
2. Create a character
3. Once in town, exit with Ctrl-X
4. Run ./xygos -mx11 -- -n4
5. Once playing with the previous save, commit suicide with Q
6. On the death screen, select the option to start a new game without exiting
7. Going through the birth process works fine, but then crashes

[Nick]

Originally Posted by backwardsEric

Changing line 350 of src/ui-mon-list.c to

if (height < 1 || width < 1 || !cave)

did let things proceed to the town, and I didn't encounter any problems after that.

Weird. Why doesn't Angband crash there, then?

[backwardsEric]

Originally Posted by Nick

Weird. Why doesn't Angband crash there, then?

From what I'm seeing, Angband does not have PR_MONLIST included in player->upkeep->redraw on that first call to redraw_stuff() while Xygos does. For Xygos, that flag is already set when event_signal(EVENT_ENTER_WORLD) is called. I didn't track down when it was set prior to that.