Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000995Zandronum[All Projects] Bugpublic2012-08-28 04:012024-03-03 01:51
ReporterNotJenova 
Assigned ToTorr Samaho 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionno change required 
PlatformLinuxOSUbuntuOS Version10.04 x86-64
Product Version1.0 
Target VersionFixed in Version 
Summary0000995: Server crash with Brutal Doom
DescriptionZandronum-server on 64 bit linux seems to crash when performing an execution with the berserk pack. We were unable to reproduce the bug on Windows, as it seems that the bug does not affect windows servers.

Here is the crash message:

zandronum-server: /home/blzut3/Code/Public/Zandronum/src/p_sight.cpp:646: bool P_CheckSight(const AActor*, const AActor*, int): Assertion `t1 != __null' failed.
Aborted

Here are the wads used:

skulltag_actors.pk3
cchest4.wad (or any wad)
brutaldoomv016b.pk3

If for some reason you need it, here is the command that was executed to start the server (in cooperative)

./zandronum-server -iwad iwads/doom2.wad -file skulltag_actors.pk3 -file cchest4.wad -file brutaldoomv016b.pk3 +sv_hostname "Test server"
Steps To ReproduceGrab the berserk pack and perform an execution on a monster.
Attached Files

- Relationships
related to 0000849closedDusk Stronghold STR20 triggers an assertion failure on server 

-  Notes
User avatar (0004493)
Edward-san (developer)
2012-08-28 09:57

 We need more informations.
Can you build zandronum in debug mode and reproduce this in gdb? We need its backtrace.

It would be more convenient if you try to reproduce this with a little example wad.
Also, since it aborts on zdoom code, the example wad should be readable by gzdoom 323 (obviously built with debug mode) in order to see if it's possible to reproduce this in the above program.
User avatar (0004495)
Dusk (developer)
2012-08-28 11:13

 Looks like 0000849 take 2 P:
User avatar (0004499)
Torr Samaho (administrator)
2012-08-28 18:43

 That's really weird. Assertions are only triggered in debug mode, you shouldn't see something like in the official binaries ever. Blzut3, you are compiling the binaries in release mode, i.e. with -DCMAKE_BUILD_TYPE=Release, aren't you?
User avatar (0004500)
Blzut3 (administrator)
2012-08-28 19:02
edited on: 2012-08-28 19:05

 Hmm that's weird. I was apparently building with the default value for CMAKE_BUILD_TYPE which does not appear to equate to any of proper values. (Produces binaries slightly larger than Release, and a lot smaller than RelWithDebInfo.) Do you want me to re-upload the binaries with that build variable properly set?

Edit: I just now noticed there's a 5th value which just uses CMAKE_CXX/C_FLAGS so that means the binaries were built with default optimization level. Question still remains though. Looks like the Mac binaries might also be affected.
User avatar (0004501)
Torr Samaho (administrator)
2012-08-28 20:05

 Would be nice if you re-upload with that build variable properly set. This will fix the issue here: P_CheckSight explicitly checks that t1 and t2 are not NULL before using them, so even with the assertion disabled, the function will not crash.
User avatar (0004503)
Blzut3 (administrator)
2012-08-29 01:19

 All right, I've replaced the old builds with CMAKE_BUILD_TYPE=Release builds. I take it you still need to remove the assertion?
User avatar (0004504)
ZzZombo (reporter)
2012-08-29 12:22

 Do I need to redownload my binary?
User avatar (0004508)
Torr Samaho (administrator)
2012-08-29 19:38
Quote from Blzut3
I take it you still need to remove the assertion?
Since CMAKE_BUILD_TYPE=Release eliminates the assertions from the binaries, there is no need to remove them. And since ZDoom put them in there for some reason, I rather keep them around.

Quote from ZzZombo
Do I need to redownload my binary?
If you are using the Linux x64 or the OS X binaries, then yes.
User avatar (0023284)
Ru5tK1ng (updater)
2024-03-03 01:51

 Since this is so old, please make a new ticket if you have issues with 3.1

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2012-08-28 04:01 NotJenova New Issue
2012-08-28 06:43 NotJenova Note Added: 0004492
2012-08-28 07:49 NotJenova Note Deleted: 0004492
2012-08-28 09:57 Edward-san Note Added: 0004493
2012-08-28 11:13 Dusk Relationship added related to 0000849
2012-08-28 11:13 Dusk Note Added: 0004495
2012-08-28 18:43 Torr Samaho Note Added: 0004499
2012-08-28 18:43 Torr Samaho Assigned To => Blzut3
2012-08-28 18:43 Torr Samaho Status new => feedback
2012-08-28 19:02 Blzut3 Note Added: 0004500
2012-08-28 19:05 Blzut3 Note Edited: 0004500 View Revisions
2012-08-28 20:05 Torr Samaho Note Added: 0004501
2012-08-29 01:19 Blzut3 Note Added: 0004503
2012-08-29 01:19 Blzut3 Assigned To Blzut3 => Torr Samaho
2012-08-29 01:19 Blzut3 Status feedback => assigned
2012-08-29 12:22 ZzZombo Note Added: 0004504
2012-08-29 19:38 Torr Samaho Note Added: 0004508
2024-03-03 01:51 Ru5tK1ng Note Added: 0023284
2024-03-03 01:51 Ru5tK1ng Status assigned => closed
2024-03-03 01:51 Ru5tK1ng Resolution open => no change required




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker