MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004206Zandronum[All Projects] Bugpublic2024-03-11 07:172024-03-15 00:24
ReporterKaapeli47 
Assigned To 
PriorityurgentSeveritycrashReproducibilityalways
StatusconfirmedResolutionopen 
PlatformLinuxOSUbuntuOS Version10.04 x86
Product Version4.0-beta 
Target VersionFixed in Version 
Summary0004206: Dropping DeHackEd-modded weapons when dying with SV_WeaponDrop crashes a Linux server
DescriptionPlaying a mod or a mapset with weapons that are modified using DeHackEd on a Linux server with the SV_WeaponDrop DMFlag enabled crashes the server, if a player dies with a weapon other than the pistol or fist equipped. The same does not happen in a locally hosted Windows server, or in either server with unmodified weapons or weapons that are modded using Decorate - with those they drop on the ground as they should and the server is fine.
Steps To Reproduce1: Start a Linux server with a mod or a mapset that modifies the classic Doom weapons through DeHackEd, such as Valiant, Struggle, or Antaresian Reliquary.
2: Set SV_WeaponDrop to true.
3: Pick up a weapon on the map and keep it equipped.
4: Get killed with the weapon equipped.
Additional InformationFirst discovered in Euroboros with Antaresian Reliquary. Also tested with a locally hosted Windows server where it doesn't crash.
TagsNo tags attached.
Relationships
related to 0003976resolved DrinkyBird Possible Problems With Dehacked Lumps in Vanilla Wads 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2024-03-11 07:17Kaapeli47New Issue
2024-03-11 07:54Ru5tK1ngNote Added: 0023349
2024-03-11 08:30KaminskyRelationship addedrelated to 0003976
2024-03-15 00:19DrinkyBirdNote Added: 0023403
2024-03-15 00:19DrinkyBirdStatusnew => confirmed
2024-03-15 00:24DrinkyBirdNote Edited: 0023403bug_revision_view_page.php?bugnote_id=23403#r14137

Notes
(0023349)
Ru5tK1ng   
2024-03-11 07:54   
This was printed out on the console before crashing on TSPG:
malloc(): invalid next size (unsorted)
(0023403)
DrinkyBird   
2024-03-15 00:19   
(edited on: 2024-03-15 00:24)
Can reproduce.

Valgrind complains:

DrinkyBird let an arachnotron get it.
==100119== Invalid write of size 4
==100119== at 0x648271: APlayerPawn::Die(AActor*, AActor*, int) (p_user.cpp:2012)
==100119== by 0x5B2D3A: P_DamageMobj(AActor*, AActor*, AActor*, int, FName, int) (p_interaction.cpp:1728)
==100119== by 0x5CCDE3: PIT_CheckThing(AActor*, FCheckPosition&) (p_map.cpp:1290)
==100119== by 0x5CD969: P_CheckPosition(AActor*, int, int, FCheckPosition&, bool) (p_map.cpp:1516)
==100119== by 0x5CEB0D: P_TryMove(AActor*, int, int, int, secplane_t const*, FCheckPosition&, bool) (p_map.cpp:1898)
==100119== by 0x5E7B62: P_XYMovement(AActor*, int, int) (p_mobj.cpp:2258)
==100119== by 0x5EDB8F: AActor::Tick() (p_mobj.cpp:4372)
==100119== by 0x49C0C6: DThinker::TickThinkers(FThinkerList*, FThinkerList*) (dthinker.cpp:472)
==100119== by 0x49BF0E: DThinker::RunThinkers() (dthinker.cpp:419)
==100119== by 0x634367: P_Ticker() (p_tick.cpp:399)
==100119== by 0x4A8DC5: G_Ticker() (g_game.cpp:1783)
==100119== by 0x6FA944: SERVER_Tick() (sv_main.cpp:742)
==100119== Address 0x6fd7c88 is 0 bytes after a block of size 1,096 alloc'd
==100119== at 0x4845828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==100119== by 0x4E3748: M_Malloc_Dbg(unsigned long, char const*, int) (m_alloc.cpp:135)
==100119== by 0x497359: PClass::CreateNew() const (dobjtype.cpp:258)
==100119== by 0x5EEE54: AActor::StaticSpawn(PClass const*, int, int, int, replace_t, bool) (p_mobj.cpp:4872)
==100119== by 0x3F1A78: Spawn(PClass const*, int, int, int, replace_t) (actor.h:1328)
==100119== by 0x5A0C2D: P_DropItem(AActor*, PClass const*, int, int) (p_enemy.cpp:3481)
==100119== by 0x648210: APlayerPawn::Die(AActor*, AActor*, int) (p_user.cpp:2007)
==100119== by 0x5B2D3A: P_DamageMobj(AActor*, AActor*, AActor*, int, FName, int) (p_interaction.cpp:1728)
==100119== by 0x5CCDE3: PIT_CheckThing(AActor*, FCheckPosition&) (p_map.cpp:1290)
==100119== by 0x5CD969: P_CheckPosition(AActor*, int, int, FCheckPosition&, bool) (p_map.cpp:1516)
==100119== by 0x5CEB0D: P_TryMove(AActor*, int, int, int, secplane_t const*, FCheckPosition&, bool) (p_map.cpp:1898)
==100119== by 0x5E7B62: P_XYMovement(AActor*, int, int) (p_mobj.cpp:2258)


I also got a GDB backtrace at operator new in NETBUFFER_s::Init, but I think this is memory corruption that malloc is detecting and blowing up over later down the line

EDIT: does seem to be an upstream bug, Valgrind complains about the same thing when under GZDoom 1.8.6. It doesn't crash though.