|
Notes |
|
|
|
|
They contain no debug info, so this can't be investigated. The server must be compiled with debug info to make sense. |
|
|
|
(0014996)
|
|
Fr3ak
|
|
2016-05-29 15:36
|
|
|
Edward-san, how do I compile a server with debug info? It's hosted on Best-Ever, if that makes any difference. |
|
|
|
|
It's up to Best-Ever's maintainer, because afair the server has the code different from the official zandronum server.
If you still wish to reproduce the problem by hosting your server, it depends on your platform. If you have Windows, you should not need to compile it, because Windows version of the server crash report should be more detailed even without debug mode. |
|
|
|
(0014999)
|
|
Fr3ak
|
|
2016-05-31 19:13
|
|
|
Edward-san, will you be able to find anything wrong if I provide a Doomseeker demo? |
|
|
|
|
|
It won't tell me much, because the demo is client-sided while the crash is server-sided, but it's worth trying. Go ahead and update a demo. |
|
|
|
(0015001)
|
|
Fr3ak
|
|
2016-06-01 03:54
|
|
|
|
|
|
|
How was the demo recorded? There's nothing useful inside. |
|
|
|
(0015199)
|
|
Fr3ak
|
|
2016-07-03 01:09
|
|
|
Oh. The game crashed offline again. If I send you a report of the offline crash, will you be able to determine the problem? |
|
|
|
(0015200)
|
|
Fr3ak
|
|
2016-07-03 01:09
|
|
|
Also, that demo was recorded with Doomseeker. |
|
|
|
(0015202)
|
|
Fr3ak
|
|
2016-07-03 02:09
|
|
|
Okay, I heard that offline crash reports can be used to find the issue. That's why I uploaded the most recent crash report right now. |
|
|
|
|
Your crash log looks like an infinite recursion involving A_JumpIfInventory and that is triggered by ACS_ExecuteAlways.
Does it still happen in the latest Zandronum 3.0 beta? |
|
|
|
(0015205)
|
|
Fr3ak
|
|
2016-07-03 14:07
|
|
|
I don't know because I do not have the 3.0 beta. I am going to look for it right now. |
|
|
|
(0015213)
|
|
Fr3ak
|
|
2016-07-05 18:25
|
|
|
|
|
(0015214)
|
|
Torr Samaho
|
2016-07-06 06:09
(edited on: 2016-07-06 06:10) |
|
Considering how long that crash log is, that looks like an infinite recursion. Is there any chance you can test this on a server running a debug build to get a more insightful crash log? Also, this is still a 2.1.2 crash log. Did you check if the crash still happens in the 3.0 betas?
|
|
|
|
|
|
I'll compile a 2.1.2 debug build and put it on TSPG Painkiller. |
|
|
|
(0015216)
|
|
DrinkyBird
|
2016-07-06 07:59
(edited on: 2016-07-06 08:44) |
|
|
|
|
|
Quote
Also, this is still a 2.1.2 crash log. Did you check if the crash still happens in the 3.0 betas?
If I recall, people said that Megaman 8BDM doesn't work with 3.0. Running his mod with 3.0 will not be possible currently. |
|
|
|
(0015232)
|
|
Fr3ak
|
|
2016-07-09 14:45
|
|
|
|
|
(0015234)
|
|
Edward-san
|
2016-07-09 15:11
(edited on: 2016-07-09 15:13) |
|
Finally a decent crash log :) .
[edit]
Quote
Can you find out what actor caused this crash at all?
Sadly this information can be accessed only with an active debugging session, although it's sure one of the player classes cause the issue.
|
|
|
|
|
|
Judging from the crash logs, it looks like an DECORATE infinite loop caused by a death state that starts with A_JumpIfInTargetInventory. Could actually be an error of the mod instead of a Zandronun error. Can somebody check the death states for A_JumpIfInTargetInventory? |
|
|
|
(0015236)
|
|
Fr3ak
|
|
2016-07-09 15:16
|
|
|
Yeah, but is there any way to find out what actor caused it? |
|
|
|
(0015244)
|
|
Fr3ak
|
|
2016-07-09 18:04
|
|
Okay, guys. Since this kind of crash has literally never happened in any other version of Justified before,
'http://static.allfearthesentinel.net/logs/cb61108c2dcb3bbc60e41332a35652c6.txt [^]'
I think it's safe to assume that it's a Zandronum issue. Nothing at all was ever changed in Justified with custom states between one version and the next. They all work the same. Is there any way you guys could investigate this at all? |
|
|
|
|
Quote from Fr3ak
Since this kind of crash has literally never happened in any other version of Justified before, I think it's safe to assume that it's a Zandronum issue.
Wait, you are saying that Zandronum works fine with any older version of Justified? Then something is changed in Justified and Zandronum starts crashing? And then you conclude that it's a Zandronum issue? I don't understand the reasoning. The only thing you can conclude is that whatever Justified changed, causes the crash. Whether it's bad DECORATE code (mod error) or an error in Zandronum is complete unclear.
Quote from Fr3ak
Is there any way you guys could investigate this at all?
As I said in 0002743:0015235: Somebody should check the death states for A_JumpIfInTargetInventory and see if there are any infinite loop. |
|
|
|
(0015246)
|
|
Fr3ak
|
|
2016-07-09 19:04
|
|
|
No, Torr. I'm saying that the Justified has literally never crashed randomly like that in any other version of Zandronum. No major changes were made to the mechanics of each Justified version, so that is why we think it is a Zandronum issue. |
|
|
|
|
I still don't see the reasoning. As long as you don't have one version of Justified that works fine in some version of Zandronum and not in another version of Zandronum, there is no evidence that the problem is more likely a Zandronum error than a mod error. It could be either.
The only real evidence we have (crash log pointing to a potential DECORATE infinite loop), make a mod error more likely than a Zandronum error.
How many actors are using A_JumpIfInTargetInventory in one of their death states in the mod? Unless this are too many, this should be a good starting point to isolate the cause of the crashes. |
|
|
|
|
It seems A_JumpIfInTargetInventory is used quite a lot in the Justified mod (see the attached text file). Good luck finding the responsible code...
|
|
|
|
(0015251)
|
|
Dusk
|
|
2016-07-10 11:24
|
|
After a lot of debugging hassle I think we found it:
ClassDeath:
CUTM H 0 A_JumpIfInTargetInventory("MegaBusterC",1,"WeaponGetM")
CUTM H 0 A_JumpIfInTargetInventory("BassBusterBoss",1,"WeaponGetB")
CUTM H 0 A_JumpIfInTargetInventory("ProtoBusterBoss",1,"WeaponGetP")
MERC H 20 ACS_ExecuteAlways(999,0,0)
MERC H 0 A_PlayerScream
NOFX A 0 A_SpawnItemEx("FakeDeathFX",0,0,32)
NOFX A 1 A_CheckPlayerDone
wait
ClassIceDeath:
MERC A 35
NOFX A 0 A_SpawnItemEx("FrozenDeathFX",0,0,16)
NOFX A 1 A_CheckPlayerDone
wait
WeaponGetJ:
CUTM H 0 A_JumpIfInTargetInventory("CrystalJoeWep",1,2)
CUTM H 0 A_GiveToTarget("WeaponGetFlag")
CUTM H 0 A_GiveToTarget("CrystalJoeWep")
goto ClassDeath
WeaponGetM:
CUTM H 0 A_JumpIfInTargetInventory("GrabBusterWepM",1,2)
CUTM H 0 A_GiveToTarget("WeaponGetFlag")
CUTM H 0 A_GiveToTarget("GrabBusterWepM")
goto ClassDeath
WeaponGetB:
CUTM H 0 A_JumpIfInTargetInventory("GrabBusterWepB",1,2)
CUTM H 0 A_GiveToTarget("WeaponGetFlag")
CUTM H 0 A_GiveToTarget("GrabBusterWepB")
goto ClassDeath
WeaponGetP:
CUTM H 0 A_JumpIfInTargetInventory("GrabBusterWepP",1,2)
CUTM H 0 A_GiveToTarget("WeaponGetFlag")
CUTM H 0 A_GiveToTarget("GrabBusterWepP")
goto ClassDeath
The actor seems to have an infinite loop here. It reaches ClassDeath + 1, where A_JumpIfInTargetInventory sends it to WeaponGetM, and at the end it goes back to ClassDeath.
Seriously. Code your mods better. And stop blaming us for your failures.
|
|
|
|
(0015252)
|
|
Fr3ak
|
|
2016-07-10 13:45
|
|
|
Dusk, that is not the crash we are trying to find the answer to. We already know about the one you just posted and we already fixed it. What we are looking for is how the game will randomly shut off during any time of the game. |
|
|
|
|
This (or something that is also creating an infinite loop in a death state) is the crash that led to your crash log from 0002743:0015232. If your mod has additional crashes, please provide crash logs that point to those.
And if you already knew about this crash and fixed it, why are you sending crash logs of an version of this mod that doesn't have this crash fixed? |
|
|
|
(0015255)
|
|
Fr3ak
|
|
2016-07-10 14:12
|
|
What I am looking for is an answer to this:'http://static.allfearthesentinel.net/logs/cb61108c2dcb3bbc60e41332a35652c6.txt [^]'
Also, we knew about the MMV crash and fixed it, but we did not release a hotfix yet. That is why I am sending logs of a version with that issue. But there are two crashes. The MMV crash, which I posted in post 0015232, and the random crash, which is found in post 0015244. We already fixed the MMV crash (which is our fault) but not the random crash (which we believe is a Zandronum issue. |
|
|
|
|
|
To make sure that I didn't misunderstand something: You knew that there are two different crashes, you already knew how to fix one of these crashes and then you send us random crash logs from which you know that they could be caused by either of these two crash reasons without telling us of the known crash? |
|
|
|
(0015259)
|
|
Fr3ak
|
|
2016-07-10 14:43
|
|
|
That is right. I accidentally posted a log of the crash we already knew about. At the time of the posting, I didn't know it was caused by that. Had I known, I would not have posted it. The one with Actor SetState is the one we want to find the answer to. That is the one we think is a Zandronum issue. |
|
|
|
|
|
The other crash happens only if the server is compiled in debug mode. Disabling the mentioned assertion could be a solution, though it would be nice to know which decorate code triggers it.. |
|
|
|
|
Quote from Fr3ak
That is right. I accidentally posted a log of the crash we already knew about. At the time of the posting, I didn't know it was caused by that. Had I known, I would not have posted it.
And you didn't even realize that it has to be the crash you knew about after I pointed to the infinite loop in a death state that starts with A_JumpIfInTargetInventory?
Anyway, make a hotfix that fixes the crash you didn't tell us about and host that with the normal aka non-debug server. If that still crashes, send a new crash log. |
|
|
|
(0015270)
|
|
Fr3ak
|
|
2016-07-10 16:37
|
|
|
|
|
|
|
If 2.1.2 doesn't generate any crash log, please try a 3.0 beta. |
|
|
|
(0015274)
|
|
Fr3ak
|
|
2016-07-10 20:15
|
|
|
One problem with that. MM8BDM-v4c.pk3 does not work with Zandronum 3.0 beta. |
|
|
|
|
|
What's the problem with 3.0? Is there a ticket for it? |
|
|
|
(0015276)
|
|
Fr3ak
|
|
2016-07-10 21:27
|
|
|
No ticket. It's just that it was never updated to be compatible with 3.0. |
|
|
|
|
|
3.0 is supposed to be fully backwards compatible with 2.1.2, so there should be no need to update the mod for 3.0. If there are compatibility problems, it is either a bug (and should be fixed in Zandronum) or one of the breaking changes ZDoom made. In any case, you should report the problems, so that we can see whether it's 3.0's fault. |
|
|
|
|
|
Closing due to lack of feedback from user. If you are still having this crash with 3.1 or the latest 3.2 beta, reopen the ticket. |
|
zandronum-crash-05_27_2016-15_48_39.29860.log (9,064) 2016-05-29 03:27
Zandronum_31.05.2016_15.09.31-Pharaoh_Crash.cld (22,217) 2016-06-01 03:54
CrashReport020.zip (36,060) 2016-07-03 02:08