|
Notes |
|
|
|
|
Can you paste your BE host command here so I can use it? |
|
|
|
|
|
It's ".host hostname="SamsaraHold 0.12: The Mission Continues!" iwad=doom2.wad wad=strnghld_v1.pk3,strnghld_violence_v4.pk3,StrongHoldEditsNFixesv1.1PatchV4.1.pk3,StrongholdItemsV7.1.pk3,samsaraHold-v0.12-core.pk3,samsaraHold-v0.12-code.pk3 dmflags=16388 dmflags2=336593152 dmflags3=16 gamemode=coop" |
|
|
|
|
That is a lot more wads than I originally thought.
Do you know if it happens to any particular one? The best thing to do is to let me know how I can minimize this to as small of a wad set as possible to get the bug to happen. If you know what wads I can remove and any other info along with this, it would help me greatly. |
|
|
|
(0011967)
|
|
Untitled
|
2015-04-01 10:56
(edited on: 2015-04-01 10:57) |
|
.host hostname="Breaking Zandronum" iwad=doom2.wad wad=strnghld_v1.pk3,StrongholdItemsV7.1.pk3 config="watastronghold.cfg" gamemode=coop
(Using watastronghold.cfg starts the map at MAP99, which results in an immediate segfault)
Got it down to two files - strnghld_v1.pk3 doesn't break by itself, actually.
At these two wads, everything crashes. BestEver will say this is a wad error.
But what kind of wad error is "Address not Mapped to Object (Signal 11)"?
|
|
|
|
|
Cool thanks!
Quote
But what kind of wad error is "Address not Mapped to Object (Signal 11)"?
It's a lower level error signal of something going wrong. I don't know if this means some kind of coding error. I'll try to find out why. |
|
|
|
|
|
Where can I get your watastronghold.cfg? |
|
|
|
|
|
|
|
|
|
It looks like I can't access the file without creating an account. Can you attach the file to this ticket? |
|
|
|
|
|
I wasn't the one who uploaded it, but it's now uploaded. |
|
|
|
(0012028)
|
|
Edward-san
|
2015-04-04 19:37
(edited on: 2015-04-04 19:40) |
|
Can you upload the involved file somewhere?
|
|
|
|
|
zandronum.exe -file strnghld_v1.pk3 StrongholdItemsV7.1.pk3 -host +exec watastronghold.cfg
doesn't crash for me under Windows. Is it possible that your version of StrongholdItemsV7.1.pk3 is corrupted? |
|
|
|
|
Hmm. Unless BestEver's StrongholdItemsV7.1.pk3 is corrupted, then it should be reproducable.
For me the big problem is this doesn't appear in single player - or using multiplayer emulation in single player - it appears to entirely be a Multiplayer problem, specifically when hosting using #BestEver.
And I can confirm this, because I annihilated another server, with a Crash Log, again.
Posted the Crash Log. |
|
|
|
(0012033)
|
|
Konar6
|
|
2015-04-04 22:45
|
|
|
Can you reproduce it on your own server? |
|
|
|
(0012034)
|
|
Edward-san
|
2015-04-04 23:26
(edited on: 2015-04-04 23:29) |
|
oh, finally a crash log with full debug info! :)
Bad news: it has nothing to do with the archive itself, but with the gl node cache file handling. What happens if you host again with 'gl_cachenodes 0'?
[edit]gl_cachenodes was introduced in 2.0. I guess servers should not enable gl node caching at all, considering that some host services run the same application with different parameters...
|
|
|
|
|
That actually worked!
Alright, I'd like to now point out a new bug:
"gl_cachenodes" can crash servers. |
|
|
|
|
@Torr, since this is likely (G)ZDoom related, do you want me to assign the ticket to you since you did the upgrading?
I don't mind attempting to fix it, though you might know how to fix it already since you did the upgrading.
|
|
|
|
|
|
I believe this can be fixed by changing the cvar to custom and forcing the cvar to be off for the servers. |
|
|
|
|
I'll take care of this.
Quote from Edward-san
I believe this can be fixed by changing the cvar to custom and forcing the cvar to be off for the servers.
Since it's an archived CVAR, changing it to false on the server would also change it in the ini, affecting clients who share the same ini. I think a better way here is to ignore the value of the cvar on the server. It's only used at a single place, so that requires only one small change. |
|
|
|
|
|
Hopefully, fixed now. Please check. |
|
|
|
(0012477)
|
|
cobalt
|
|
2015-05-31 17:30
|
|
Issue addressed by commit c51cf7826429: Fixed: "gl_cachenodes 1" could crash the server (fixes 2152).
Committed by Benjamin Berkels [Torr Samaho] on Sunday 31 May 2015 19:25:40
Changes in files:
docs/zandronum-history.txt | 1 +
src/gl/data/gl_nodes.cpp | 3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
|
|
FatalErrorCrash.txt (9,749) 2015-04-01 00:51