[ANNOUNCE] NPPAngband 6.1.1

[nppangband]

The final NPPAngband 6.1.1 has been released. This fixes a couple bugs, including one that could cause the game to crash when inspecting weapons.

The complete changelist is:

Bugfix: Fixed a bug where the game could crash when inspecting a weapon.
Bugfix: Fixed 2 bugs regarding the description of the firing speed of a missile launcher.

The links are:

Souce Code:

http://download.nppangband.org/npp-6.1.1-src.zip

Windows Binary:

http://download.nppangband.org/npp-6.1.1-win.zip

Mac Binary:

http://download.nppangband.org/npp-6.1.1-osx.zip

Github respository:

https://github.com/nppangband/NPPAngband

[AnonymousHero]

I was trying to compile using clang and found this:

randart.c:3912:21: warning: will never be executed [-Wunreachable-code]
                prep_object_theme(theme);
                                  ^~~~~

I looked it up and found the code:

		/*prepare the object template*/
		object_wipe(o_ptr);

		/*get the obejct number test it for appropriate power*/
		while (TRUE)
	   	{
			theme = get_theme();

			/*hack - we con't need any more artifact digging tools*/
			if (theme == DROP_TYPE_DIGGING) continue;
		}

		/*prepare the object generation level for a specific theme*/
		prep_object_theme(theme);

		k_idx = 0;

AFAICT the loop has no hope of ever terminating... am I mistaken?

[nppangband]

You are correct. There should be a break statement after

/*hack - we con't need any more artifact digging tools*/
if (theme == DROP_TYPE_DIGGING) continue;

Good catch. This has been undiscovered for years, just because it is inside an if statement that has gone unused. The game has always determined the object (long sword, leather armor, etc) before calling the make_one_randart function. Good thing, or it would have froze up at that one point.

Still, I will fix that. Thanks.

[AnonymousHero]

The bug reported for 6.1.0 is still present, but oddly enough not when you compile with Clang.

Another observation: Saving the game does not work (nothing happens) when the game was compiled with GCC, but does work when compiled with GCC.

I'm guessing it something to do with one of the huge number of warnings that are spewed out by both Clang and GCC, but I don't have time to investigate further.

[nppangband]

The bug reported for 6.1.0 is still present, but oddly enough not when you compile with Clang.

I looked into that as best I can. I have an ubuntu machine, and with 1-2 changes to makefiles, both the sdl and gcu ports compiled and ran fine. Ubuntu uses GCU to compile, so I am having a hard time imagining what may be happening there.

Another observation: Saving the game does not work (nothing happens) when the game was compiled with GCC, but does work when compiled with GCC.

Is that second "GCC" supposed to be clang, or the first?

I'm guessing it something to do with one of the huge number of warnings that are spewed out by both Clang and GCC, but I don't have time to investigate further.

I don't blame you. Again, strange, since I don't get any warnings compiling with GCC in ubuntu. However I would do my best to clean them up if you sent me a list of the warnings.

Pity. I thought once I bought myself a notebook air, and converted an old windows machine to linux I would be able to cover all issues on all platforms.

[AnonymousHero]

Is that second "GCC" supposed to be clang, or the first?

Whoops, the second was supposed to be Clang. So just to clarify (nested quoting on this forum appears to be wonky): Saving the game does nothing with GCC, but works with Clang.

I'll see about getting a full list of warnings.

Btw, are compiling with 32-bit or 64-bit?

[nppangband]

32 bit. It's an old machine. I might just try to load arch linux on it and try to see this for myself. What command line are you using to compile?

[AnonymousHero]

32 bit. It's an old machine. I might just try to load arch linux on it and try to see this for myself. What command line are you using to compile?

The standard one. (Well, with an added "-g" just to get a usable stack trace.)

Since you're using 32-bit I'm guessing that that's it. I'm on 64-bit.

I wouldn't bother trying to install Arch -- it's pretty non-trivial to install, so unless you want a challenge...

[AnonymousHero]

Oh, and is there an e-mail address I can send the warnings to? (Feel free to PM it to me if you don't want it public).

[nppangband]

Thank you very much for sending that. The e-mail address is on the splashscreen:

nppangbanddev at verizon dot net

[AnonymousHero]

I've submitted a pull request to fix all the trivial warnings and I've pasted the rest here:

gcc output
clang output

[nppangband]

Many thanks. I will gladly accept the pull request.

-Jeff

[AnonymousHero]

Two pull requests up now.

[nppangband]

Two pull requests up now.

Thank you again.

Same here. Here's the segfault location:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004a4863 in get_obj_num (level=1) at object2.c:72
72                      if (table[i].level > level) break;

values of note:

(gdb) print i
$1 = 0
(gdb) print table
$2 = (alloc_entry *) 0x0

So the table pointer seems to be NULL.

Above is pasted in from the NPP 6.1.0 announcement thread.

It occured to me that, even if I can't duplicate the bug on my computers, I should still be able to eliminate it. All I have to do is make sure the null variable is defined.

As I reading this right? Is this saying that table[i].level is null, or level? Is level = 1 and table[i].level undefined?

Thanks. If it is table[i] level, I can always add something at game startup to make sure all values start at 0. Shouldn't that solve the problem?

[AnonymousHero]

It's "table" itself that's NULL. I think I might have a stab at trying to figure out why during this weekend -- I'm guessing it's caused by the same problem that causes saving to fail silently.