Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
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.
Attached Files

- Relationships
related to 0003976resolvedDrinkyBird Possible Problems With Dehacked Lumps in Vanilla Wads 

-  Notes
User avatar (0023349)
Ru5tK1ng (updater)
2024-03-11 07:54

This was printed out on the console before crashing on TSPG:
malloc(): invalid next size (unsorted)
User avatar (0023403)
DrinkyBird (developer)
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.


Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2024-03-11 07:17 Kaapeli47 New Issue
2024-03-11 07:54 Ru5tK1ng Note Added: 0023349
2024-03-11 08:30 Kaminsky Relationship added related to 0003976
2024-03-15 00:19 DrinkyBird Note Added: 0023403
2024-03-15 00:19 DrinkyBird Status new => confirmed
2024-03-15 00:24 DrinkyBird Note Edited: 0023403 View Revisions






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker