MantisBT - Zandronum
View Issue Details
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.
Additional Information
TagsNo tags attached.
Relationships
related to 0000849closed Dusk Stronghold STR20 triggers an assertion failure on server 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-08-28 04:01NotJenovaNew Issue
2012-08-28 06:43NotJenovaNote Added: 0004492
2012-08-28 07:49NotJenovaNote Deleted: 0004492
2012-08-28 09:57Edward-sanNote Added: 0004493
2012-08-28 11:13DuskRelationship addedrelated to 0000849
2012-08-28 11:13DuskNote Added: 0004495
2012-08-28 18:43Torr SamahoNote Added: 0004499
2012-08-28 18:43Torr SamahoAssigned To => Blzut3
2012-08-28 18:43Torr SamahoStatusnew => feedback
2012-08-28 19:02Blzut3Note Added: 0004500
2012-08-28 19:05Blzut3Note Edited: 0004500bug_revision_view_page.php?bugnote_id=4500#r2459
2012-08-28 20:05Torr SamahoNote Added: 0004501
2012-08-29 01:19Blzut3Note Added: 0004503
2012-08-29 01:19Blzut3Assigned ToBlzut3 => Torr Samaho
2012-08-29 01:19Blzut3Statusfeedback => assigned
2012-08-29 12:22ZzZomboNote Added: 0004504
2012-08-29 19:38Torr SamahoNote Added: 0004508
2024-03-03 01:51Ru5tK1ngNote Added: 0023284
2024-03-03 01:51Ru5tK1ngStatusassigned => closed
2024-03-03 01:51Ru5tK1ngResolutionopen => no change required

Notes
(0004493)
Edward-san   
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.
(0004495)
Dusk   
2012-08-28 11:13   
Looks like 0000849 take 2 P:
(0004499)
Torr Samaho   
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?
(0004500)
Blzut3   
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.
(0004501)
Torr Samaho   
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.
(0004503)
Blzut3   
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?
(0004504)
ZzZombo   
2012-08-29 12:22   
Do I need to redownload my binary?
(0004508)
Torr Samaho   
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.
(0023284)
Ru5tK1ng   
2024-03-03 01:51   
Since this is so old, please make a new ticket if you have issues with 3.1