Typical Christian

•July 11, 2019 • 1 Comment

2019-07-10 — Got this comment yesterday…

Typical ignorant cowardly Christian fuckwad. “I’m a Christian bitch”, lolz. Either he’s too illiterate or too in the closet to put a comma in there.

Banned in Pakistan

•December 9, 2018 • 2 Comments

2018-12-09 — Banned in Pakistan

Hello,

A Pakistan authority has demanded that we disable the following content on your WordPress.com site:

scaryreasoner.wordpress.com

Unfortunately, we must comply to keep WordPress.com accessible for everyone in the region. As a result, we have disabled this content only for Internet visitors originating from Pakistan. They will instead see a message explaining why the content was blocked.

Visitors from outside of Pakistan are not affected.
[…]
— Begin complaint —
Dear WordPress Team,

I am writing on behalf of Web Analysis Team of Pakistan Telecommunication Authority (PTA) which has been designated for taking appropriate measures for regulating Internet Content in line with the prevailing laws of Islamic Republic of Pakistan.

In lieu of above it is highlighted that few of the web pages hosted on your platform are extremely Blasphemous and are hurting the sentiments of many Muslims around Pakistan. The same has also been declared blasphemous under Pakistan Peal Code section 295- B and is in clear violation of Section 37 of Prevention of Electronic Crime Act (PECA) 2016 and Section 19 of Constitution of Pakistan.
[…]

Oh noes, I have hurted someones feelings.

Lolz. Guess I won’t be visiting Pakistan any time ever.

Rocket Launch as Viewed from Space

•November 24, 2018 • 2 Comments

November 24, 2018 — Rocket launch as viewed from space.

via metafilter.

Six Years of Space Nerds In Space

•November 3, 2018 • Leave a Comment

November 3rd, 2018 — Six years ago I began working on Space Nerds in Space as a hobby project, little knowing what it would become.

Sunday Morning Debugging

•September 16, 2018 • Leave a Comment

Sunday, September 16, 2018 — This morning I experienced an unexpected crash of snis_client shortly after making a warp gate jump from one solarsystem to another. While a crash is not an earth shaking surprise, they generally happen while I’m in the midst of working on something, and generally have some relation to what I’m working on. In this case, I couldn’t think of anything I had done recently that should be causing snis_client to crash.

Luckily, I had just compiled without optimization, but unluckily, I had forgotten to type “ulimit -c unlimited”, so I didn’t get a core file. Rats. Well, better luck next time. I tried for about 15 minutes to get the crash to happen again, but without any clear idea of what the cause might have been, I didn’t have any luck.

Then I remembered to look in /var/log/syslog:

wombat space-nerds-in-space # grep snis /var/log/syslog
Sep 16 09:49:48 wombat kernel: [ 6809.248896] snis_client[14897]: segfault at ab000925ddc ip 0000000000488f71 sp 00007ffe800e19d0 error 4 in snis_client[400000+108000]

So that number after “ip” is the address of the instruction pointer at the time of the crash. So let’s fire up gdb…

wombat space-nerds-in-space $ gdb ./snis_client
[...]
(gdb) info symbol 0x0000000000488f71
show_death_screen + 800 in section .text

Apparently the crash happened 800 bytes into the function show_death_screen().

show_death_screen()? That’s interesting. Apparently my crew had somehow died one way or another whilst in the midst of warping from one solarsystem to another!

Disassembling the region around the crash:

(gdb) dissassemble show_death_screen
[... many lines omitted ...]
   0x0000000000488f5c <779>:	mov    0x284516(%rip),%eax        # 0x70d478 <my_ship_oid>
   0x0000000000488f62 <785>:	mov    %eax,%eax
   0x0000000000488f64 <787>:	imul   $0xab0,%rax,%rax
   0x0000000000488f6b <794>:	add    $0x92688c,%rax
   0x0000000000488f71 <800>:	mov    (%rax),%edx
   0x0000000000488f73 <802>:	lea    -0x70(%rbp),%rax
   0x0000000000488f77 <806>:	mov    $0x4ee175,%esi
   0x0000000000488f7c <811>:	mov    %rax,%rdi
   0x0000000000488f7f <814>:	mov    $0x0,%eax
   0x0000000000488f84 <819>:	callq  0x4100a0 <sprintf@plt>
[...]

It looks like it’s setting up to call sprintf, and just before that, accessing a variable my_ship_oid, which is supposed to contain an index into a global “game object” array, go[] for short. The index it is supposed to contain corresponds to the go[] array entry that contains data for the player’s ship. Here’s the corresponding C code around the crash site:

10634                   sprintf(buf, "RESPAWNING IN %d SECONDS", go[my_ship_oid].respawn_time);
10635                   sng_abs_xy_draw_string(buf, TINY_FONT, txx(20), txy(500));
10636           }

From that, I expect my_ship_oid was not a valid index into the go[] array at the time of the crash. How could that be? Well, the last thing I did was warp into a new solarsystem, which involves the snis_client process disconnecting from one snis_server process and connecting to another, different snis_server process. One of the things that happens during the handshaking process is the snis_server process sends the object ID to use for the player’s ship over to the client. On the client side, the code to accept this information looks like this:

static int process_client_id_packet(void)
{
        unsigned char buffer[100];
        uint32_t id;
        int rc;

        assert(sizeof(buffer) > sizeof(struct client_ship_id_packet) - sizeof(uint8_t));
        rc = read_and_unpack_buffer(buffer, "w", &id);
        if (rc)
                return rc;
        my_ship_id = id;
        my_ship_oid = UNKNOWN_ID;

UNKNOWN_ID has the value -1 (or 0xffffffff if interpreted as an unsigned int), which is not a valid index into the go[] array.

Necessarily, this happens before the snis_client has determined an entry in the go[] array to use for the player ship. So there is a short period of time immediately after warping into a solarsystem (connecting to a snis_server process) during which my_ship_oid does not contain a valid index into the go[] array.

So what this means is whenever I need to access go[my_ship_oid}, I need to be careful that my_ship_oid is valid. Turns out that most of these accesses are encapsulated in a single function, find_my_ship(), and most of the time, it’s already done safely, but there were a few places where it wasn’t done safely, and if your crew happened to asphyxiate just as they warped into a new solarsystem, the code tripped over one of these unsafe accesses.

I should point out there is an additional hazard to watch out for, which is multithreading. That is to say, it’s not enough to check that my_ship_oid is valid, this check, and the usage of my_ship_oid must occur with the protection of a mutex, so that it isn’t modified by another thread between the safety check and the usage. In this case, that holds true because show_death_screen is called from main_da_expose(), and that is triggered by a call to gdk_window_invalidate_rect() from within advance_game() while the universe_mutex is held.

The fix for this problem is here.

Space Monsters!

•February 26, 2018 • Leave a Comment

February 26, 2018 — I’ve been working on adding Space Monsters into Space Nerds In Space.

 

I had worked on this before, but in my previous implementation, all the work of generating the space monster’s tentacle movements was done on the server side, and a lot of per-tentacle-segment information was transmitted from the server to each client, which was not a very good design, and I had never pushed any of this code to the main repository.  This new implementation avoids that problem. The motion of the tentacles is random. On the server side, a new per-monster seed value is periodically generated and transmitted to the clients. The clients use this to seed a per-monster Mersenne Twister which is then used to generate new desired tentacle segment joint angles, and the monster’s tentacles are gradually moved to conform to these new desired angles. The result is that multiple clients will see the monsters with consistent tentacle positions which are all genereted client side, with only the seed generated on the server and transmitted over the network. It seems to work quite well.

The space monsters are made from two meshes, one for the head or torso, and one for each tentacle segment. The albedo and emittance textures are static, and are derived from Gray Scott reaction diffusion patterns. The variable lighting effect is done by passing an emittance intensity value to the shader which is used to modulate the emittance color values.

Some problems remain. The tentacles do not avoid each other, and may pass through one another. I think this is a pretty hard problem to solve without unduly restricting each tentacle’s range of motion.

I still need to work on the behavior of the space monsters. Right now, they periodically choose a new random direction and change course to begin moving in that direction, and that is the extent of it. When velocity is low, this can produce rapid and very unnatural looking rotations, as only the overall velocity is controlled, while the orientation is simply derived from the velocity by making the space monster’s mouth face in the direction of motion.

Space Nerds In Space Navigation Tutorial

•December 4, 2017 • Leave a Comment

December 4, 2017 — Here’s a tutorial about how the Navigation screen works in Space Nerds In Space.