Nightlies embark on long journey towards 3.3

[Magnate]

After screwing around with git bisect, the last commit with 'old pvals' is apparently:
git checkout e1812132

- Frank

What are you looking for? If you want to play 3.2, you can "git checkout v3.2.0" to get that exact version - or of course just download it straight from rephial.org.

If you want to play with e1812132 that's fine, it has a few of the changes since 3.2.

[ChodTheWacko]

What are you looking for? If you want to play 3.2, you can "git checkout v3.2.0" to get that exact version - or of course just download it straight from rephial.org.

If you want to play with e1812132 that's fine, it has a few of the changes since 3.2.

I just wanted something recent with working randarts that I can play and debug if necessary ( I have a couple of weird glitches that I'm not going to report yet )

Thanks for the reply!

- Frank

[PowerDiver]

I don't remember the exact message, but my game froze with

A gruesome software bug leaps at you! panic save succeeded

Prior to this, my arrows inscribe f0 were being printed with some non-std characters. I think it was an 'h' that caused the crash. I got some output to my terminal:

08138000-0814c000 rw-p 00000000 00:00 0 
0a107000-0c256000 rw-p 00000000 00:00 0          [heap]
b7700000-b7721000 rw-p 00000000 00:00 0 
b7721000-b7800000 ---p 00000000 00:00 0 
b7833000-b785b000 rw-p 00000000 00:00 0 
b786a000-b786c000 rw-p 00000000 00:00 0 
bfc4c000-bfc61000 rw-p 00000000 00:00 0          [stack]

[d_m]

I don't remember the exact message, but my game froze with

A gruesome software bug leaps at you! panic save succeeded

Prior to this, my arrows inscribe f0 were being printed with some non-std characters. I think it was an 'h' that caused the crash.

Ugh!

I think there are some memory corruption issues that have been introduced with some of the big refactors going on. I also think similar refactors may have caused the bug where the message "You see a XYZ" occasionally gets printed N times instead of once.

[PowerDiver]

Ugh!

I think there are some memory corruption issues that have been introduced with some of the big refactors going on. I also think similar refactors may have caused the bug where the message "You see a XYZ" occasionally gets printed N times instead of once.

I guess I am running through gdb for the forseeable future. I don't yet know if this is reproducible. I started up again, shot a few arrows inscribed f0 [4 I think] and then a bunch with no inscription. I plan to save and reload, but first I'll copy some messages.

I really wish recent messages got dumped in the char dump even when you didn't just die.

A couple messages with increasing numbers:

You combine 57 arrows (1d4) (+0, +0) {f0} in your quiver (n).

Then several increases with the f0 missing up to 63
You combine 59 arrows (1d4) (+0, +0) {} in your quiver (n).

Somewhere in there I wield one arrow of wounding into the quiver. Then I pick up another arrow, I think one I shot from the ones with empty {} inscription.

You have 62 arrows (1d4) (+0, +0) {0C-??}
where the ?? are chars I do not know how to type, first a + over a - and second a superscore [an _ but up high]

Woohoo! -- it saved and reloaded with the strange inscription. Savefile available if you want it.

[takkaria]

I guess I am running through gdb for the forseeable future. I don't yet know if this is reproducible. I started up again, shot a few arrows inscribed f0 [4 I think] and then a bunch with no inscription. I plan to save and reload, but first I'll copy some messages.

I really wish recent messages got dumped in the char dump even when you didn't just die.

A couple messages with increasing numbers:

You combine 57 arrows (1d4) (+0, +0) {f0} in your quiver (n).

Then several increases with the f0 missing up to 63
You combine 59 arrows (1d4) (+0, +0) {} in your quiver (n).

Somewhere in there I wield one arrow of wounding into the quiver. Then I pick up another arrow, I think one I shot from the ones with empty {} inscription.

You have 62 arrows (1d4) (+0, +0) {0C-??}
where the ?? are chars I do not know how to type, first a + over a - and second a superscore [an _ but up high]

Woohoo! -- it saved and reloaded with the strange inscription. Savefile available if you want it.

OK, with that info I know where the problem is: wield_item():cmd-obj.c needs fixing to take account of how inscriptions work now. Previously, they were stored as references into a big array of inscriptions that was never freed, only added to (quarks). Now each item contains its own inscription, and what's happening is wield_item hasn't been modified to take account of that. Not got the time to figure it out myself for a little while, though...

[PowerDiver]

In yet another strangeness, I had two staves of teleport stacked and a third one unstacked in my pack that did not merge. The cause has something to do with my !* autoinscription. When I uninscribed the one, they merged and kept the !*. Of course, my savefile may be corrupted by the back-and-forth.

This had been fixed in what I got from git clone on 2011/01/03 but has reverted to buggy behavior [uninscribed not merging with inscribed] in what I got from git clone on 2011/01/13.

[Magnate]

This had been fixed in what I got from git clone on 2011/01/03 but has reverted to buggy behavior [uninscribed not merging with inscribed] in what I got from git clone on 2011/01/13.

This is because the memory-leak-causing inscriptions change (quark removal) was reverted in between, nuking the fix. Sorry. Was there a ticket I can reopen?

[PowerDiver]

This is because the memory-leak-causing inscriptions change (quark removal) was reverted in between, nuking the fix. Sorry. Was there a ticket I can reopen?

It got fixed before I got around to opening a ticket, so I didn't bother.

[PowerDiver]

This is because the memory-leak-causing inscriptions change (quark removal) was reverted in between, nuking the fix.

Wait a minute. A memory leak with quarks shouldn't be possible unless you are working too hard. Store the strings sequentially in a huge array, and don't ever remove anything. On level change, do garbage collection and compact the array. Is whatever alternative that is in use now worth the effort?

[PowerDiver]

I identified a blessed weapon because my pack was full and I had a rod of ID. Usually I test-wield, and toss blessed weapons unless they have ESP. This one provided protection from confusion, and I did a double-take before realizing the long-awaited changes of some high resists into abilities must be in 3.3 dev already.

[Magnate]

Wait a minute. A memory leak with quarks shouldn't be possible unless you are working too hard. Store the strings sequentially in a huge array, and don't ever remove anything. On level change, do garbage collection and compact the array. Is whatever alternative that is in use now worth the effort?

The memory leaks were caused by the *removal* of the quark array. It used to work exactly as you describe, then we tried to remove the global quark array and make inscriptions a property of each object, but that caused the leaks. We reverted to the quark arrangement until we've rationalised all the object copying and modification code, to make it easier to debug quark removal next time.

[Magnate]

I identified a blessed weapon because my pack was full and I had a rod of ID. Usually I test-wield, and toss blessed weapons unless they have ESP. This one provided protection from confusion, and I did a double-take before realizing the long-awaited changes of some high resists into abilities must be in 3.3 dev already.

Yes, that went in a week or two ago. The clue should be in the resists screen: rConf is now shown as pConf and is grouped with pFear and pBlnd.

[PowerDiver]

The memory leaks were caused by the *removal* of the quark array. It used to work exactly as you describe, then we tried to remove the global quark array and make inscriptions a property of each object

Why would you change that? That means when you fire an arrow, you either have to generate a new string or else you have to keep reference counts. Either way lies madness.

I thought in this code linked lists are considered too dangerous to implement. Reference counts are an order of magnitude worse.

[Magnate]

Why would you change that? That means when you fire an arrow, you either have to generate a new string or else you have to keep reference counts. Either way lies madness.

I thought in this code linked lists are considered too dangerous to implement. Reference counts are an order of magnitude worse.

No, the current thinking is that globals are bad and should be removed where possible. I didn't do this refactor so I don't know what the solution was (a linked list, maybe?), but it's been reverted for the time being.