Up to Main Index                           Up to Journal for October, 2020

                   JOURNAL FOR SATURDAY 24TH OCTOBER, 2020

SUBJECT: Mysterious nil pointer fixed
   DATE: Sat 24 Oct 19:29:39 BST 2020

Do you remember when I wrote about the v0.0.16 release[1] I said “I had a
weird nil pointer panic occur”, and that I couldn’t reproduce the issue and
decided not to let it hold up the release? It happened again, and I found and
fixed the problem :) Fix is on the public dev branch.

When I changed the frontend from monitoring for the QUIT command to using a
location of nil[2] to detect when players leave the game world I introduced a
subtle data race:

  func (g *game) process() {
    l := attr.FindLocate(g.player)
    if l.Where() != nil {
      // *** RACE CAN HAPPEN HERE ***
      cmd.Parse(g.player, string(g.input))
    if l.Where() == nil {
      g.buf = message.AcquireBuffer()

Note, I’ve left out comments and blank lines in the above code for brevity.

The data race happens because there is a window of opportunity between the ‘if
l.Where()’ check and the ‘cmd.Parse’ call. What can happen is: l.Where() not
nil, player killed — l.Where() is now nil, cmd.Parse called — bad things
happen :( The chances of this happing are very tiny[3], most people won’t see
it happen, hence difficult to reproduce and me left scratching my head…

In other news, I’ve been working on item resets again — only so that I can get
mobiles resetting using their items properly. I’m still aiming to have this
working for the planned Halloween release. Whether the changes will be ready
in time I don’t know yet.

Only 7 days left to Halloween… /\oo/\


  [1] “A delayed post from the release…”: ../9/19.html

  [2] Players can now exit the game world by being killed, so monitoring for
      the QUIT command no longer works.

  [3] Terry Pratchett, Mort: “million-to-one chances crop up nine times out of

  Up to Main Index                           Up to Journal for October, 2020