Bug Reports

by eihrul on 09/03/2008 01:41, 1175 messages, last message: 12/31/2023 08:39, 923516 views, last view: 04/29/2024 05:42

Please post your bug reports in here.

With your bug report, please submit the following information:

1) OS: Your operating system, i.e. Linux, Windows, or otherwise and what version you are using.

2) 3D card: The 3D card you are using. If you do not know, this is printed on the "Renderer:" line in the console when Sauerbraten starts up.

3) The edition of Sauerbraten you are using, i.e. Assassin edition, CVS as of a particular date, or otherwise.

4) Error information: If you are on Windows, a pop-up message showing filenames and line numbers should show up when Sauerbraten crashes; if possible, post a screenshot or a copy/paste of this. If on Linux, post a log of the startup info from the console, including relevant errors or any info you might have discovered. If on MacOS X, please post the crash log if applicable.

5) A description of the problem and how to reproduce it. Please give as much detail as possible on how someone can recreate the problem, in as certain terms as you can. If someone else can't reproduce the problem, it is unlikely he can fix it or tell you what is wrong.

   Board Index   

#900: Re: Bright diagonal half plane with textures that use normal

by tempest on 09/28/2012 18:42, refers to #899

I think that appears on parallax-mapped textures only (as ThomasT said, until you /calclight).

reply to this message

#901: Re: Bright diagonal half plane with textures that use normal

by Quin on 09/28/2012 19:03, refers to #900

Yes.

reply to this message

#902: NULL deref in enet_protocol_remove_sent_reliable_command

by ThomasT on 09/30/2012 02:14

There is a potential NULL dereference in enet_protocol_remove_sent_reliable_command (in protocol.c).

The lines starting at 325 are:

commandNumber = (ENetProtocolCommand) (outgoingCommand -> command.header.command & ENET_PROTOCOL_COMMAND_MASK);
enet_list_remove(...);
if (outgoingCommand->packet != NULL)
{
[...]
}
[...]
enet_free(outgoingCommand);

They should be:

if (outgoingCommand) {
commandNumber = (ENetProtocolCommand) (outgoingCommand -> command.header.command & ENET_PROTOCOL_COMMAND_MASK);
enet_list_remove(...);
if (outgoingCommand->packet != NULL)
{
[...]
}
[...]
enet_free(outgoingCommand);
}

In other words, all uses of outgoingCommand at and after line 325 need to be enclosed in a conditional block since outgoingCommand could be uninitialized.

Found using the Mac OS X XCode static analysis compilation. This may be a very minor issue if the command queues are always guaranteed to be nonempty upon entry to the function. However, even so, technically it is a bug.

reply to this message

#903: Re: Bright diagonal half plane with textures that use normal

by ThomasT on 09/30/2012 02:17, refers to #900

Most definitely not just parallax-mapped textures. I see it for pretty much any texture that has a normal map (bumpspecworld for example, which only uses 0 and n, and not z). However, that isn't important. I only mention it for the sake of clarification.

(As an aside, it's been entertaining experimenting with the various texture modes. Kudos for implementing them!)

reply to this message

#904: Re: Weapon Changes

by ThomasT on 09/30/2012 02:22, refers to #874

> Razgriz #874: Anyway, what you describe is normal.
> Otherwise it would be possible to instant fire all
> weapons without waiting for the reload by swapping > rapidly.

Not necessarily. It depends of course on how realistic you want to be. Some games I have played work as follows. When you have emptied a magazine and need to reload, you can quickly switch to a different weapon (say a side arm) and keep firing. However, switching to the original weapon still results in a reload delay because you still need to reload it.

In other words, the reload is done if necessary before you can fire the weapon, but you can still switch to a different weapon immediately before reloading. However, you may need to reload that new weapon before you can fire it.

This is a more realistic model. To make it even more realistic, you can introduce a positioning delay. Thus small weapons such as pistols can be fired quickly after switching to them, but heavier weapons would take more time due to positioning.

(Pardon the resurrection of this subthread. I was having trouble posting it for a couple of weeks due to "issues" with the forum validation. I think the problem is now "fixed", maybe, perhaps, sigh.)

reply to this message

#905: Re: NULL deref in enet_protocol_remove_sent_reliable_command

by eihrul on 09/30/2012 16:33, refers to #902

It's not possible for outgoingCommand to ever be NULL if you read the code critically. It is a failure of the analysis tool to realize it - that's the only bug - in the analysis tool. Do not blindly assume just because the tool said it that it is correct.

reply to this message

#906: Re: Bright diagonal half plane with textures that use normal

by suicizer01 on 09/30/2012 16:33, refers to #903

Maybe this node could be quiet useful if you're interested in the shader-settings.
http://quadropolis.us/node/3224

reply to this message

#907: Re: NULL deref in enet_protocol_remove_sent_reliable_command

by ThomasT on 09/30/2012 18:49, refers to #905

eihrul: I understand. That is why I said that if the queues are guaranteed to never be empty it is a very minor issue. However, if the code changes structure in the future this could turn into a problem. It all depends on how robust we'd want to make the code.

reply to this message

#908: Re: NULL deref in enet_protocol_remove_sent_reliable_command

by eihrul on 09/30/2012 19:09, refers to #907

You did not read the code critically as I asked. Otherwise, you would have noticed if the queues are empty it will still never get there. The function always returns before that happens.

reply to this message

#909: Re: NULL deref in enet_protocol_remove_sent_reliable_command

by ThomasT on 09/30/2012 19:11, refers to #907

eihrul: Ah. Now I see. I missed the nested conditional on lines 207-208 that cuts the routine short if both queues are empty. (Generally I try to avoid multiple returns from functions since it can complicate the code analysis, but I understand why it is done.)

reply to this message

#910: Re: Bright diagonal half plane with textures that use normal

by ThomasT on 09/30/2012 19:20, refers to #906

> suicizer: Maybe this node could be quiet useful if
> you're interested in the shader-settings.
> http://quadropolis.us/node/3224

Thanks, suicizer. I had in fact found that node and had downloaded it. Also, the node had been split so I also downloaded:

http://quadropolis.us/node/3357

Thanks for putting those together. They have been helpful!

reply to this message

#911: Re: Bright diagonal half plane with textures that use normal

by suicizer01 on 10/02/2012 01:00, refers to #910

As you seems interested into prefabrications (and their explanation), here's another one, but for (map)models.

http://quadropolis.us/node/3091

reply to this message

#912: Game crash in guionclear

by ThomasT on 10/03/2012 18:48

The game crashes in guionclear if you bounce in and out of the Bot Match -> Start Match menus a couple of times. (System: Mac OS X 10.6.8, SVN release.)

I've reproduced the issue in a couple of different ways, but the easiest way seems to be to click on the Bot Match menu, click on the Start Match menu, then hit Esc Esc to go back to the main menu. Repeat.

The cause appears to be in the way the menu system handles deleting the onclear member of the menu struct in menus.cpp (line 17). Running Guard Malloc for example has caught the menus->clear() method (lines 31-34 of menus.cpp) attempting to free an invalid pointer.

Note that in at least some source bases, menu->clear() calls DELETEA(m->onclear), which will NULL the pointer after deleting it. However, the current SVN release code doesn't do that. It simply (sometimes) deletes the allocated buffer using freecode(), but leaves the (now invalid) pointer intact.

Unfortunately, the guionclear command is undocumented as far as I can tell. Also, it appears to only be used by the Bot Match menu. I'm a little uncertain as to why it is used exclusively for that menu, but it could explain why such a severe issue has remained, since that code path isn't executed very often.

reply to this message

#913: Re: Game crash in guionclear

by eihrul on 10/03/2012 20:21, refers to #912

Fixed.

reply to this message

#914: off by one bug in renderva.cpp

by cristiv on 10/19/2012 09:08

I tried loading the "masdm" map with a Windows 64 bit debug-mode binary and an assertion got tripped in renderva.cpp at line 1162.

lmid+1 goes past the end of the lightmaptexs vector. Looks like there's a similar problem in line 1165.

reply to this message

#915: Re: off by one bug in renderva.cpp

by eihrul on 10/19/2012 15:50, refers to #914

This was a bug in how the lightmapper dealt with texture blending + ambient-only lighting on certain surfaces. I fixed it and relit masdm. I don't know if other maps may have bugged surfaces in them or not, but didn't seem like it - just masdm.

reply to this message

#916: Re: off by one bug in renderva.cpp

by cristiv on 10/20/2012 07:48, refers to #915

I updated from SVN and rebuilt. No more assertions. BTW, in my source tree I replaced ASSERT's definition from "int 3" to "DebugBreak()". Thanks for the quick fix.

reply to this message

#917: bad AVIs with development version

by cristiv on 10/20/2012 07:59

When I take video recordings using the development code from SVN I end up with non-playable AVI files.

This happens with both 32 and 64 bit executables. I tried /movieaccel 0, no cigar. Also tried different screen sizes and fps.

The "official" Justice Edition release works fine.

OS: Windows 7 Ultimate 64 bit
Video: NVIDIA GeForce 8400GS/PCIe/SSE2
Driver 3.3.0

reply to this message

#918: Re: bad AVIs with development version

by eihrul on 10/20/2012 08:07, refers to #917

Try a different video player?

reply to this message

#919: Re: bad AVIs with development version

by cristiv on 10/20/2012 11:12, refers to #918

mplayer's not happy either. I get the sound but the video freezes after a few frames.

reply to this message

   Board Index