[r296] Fatal crash after GZDoom startup.

[playerlin]

My GZDoom crashed after GZDoom startup.
(When the main menu appears then it crashed after about 2 seconds.)
And when I close the "Fatal crash window" , the console window(GZDoom's) still no respones, I must force to close it.

I backup and killed my old ini file and it works fine again.
I changed to use r295 and it totally fine with my ini.

Now I still use r295. I'm lazy to reset my whole old setting...

[playerlin]

Update : I try use command-line argument "-nosound" and it totally works fine.

Oh ****, not again...
Damnit...looks like it's fmod's problem again.

[Enjay]

If you are using the builds from the DRD SVN downloads, can you check the versions of FMODEX.DLL that come with the different downloads? I don't think I updated FMODEX between r295 and r296 but I can't be certain and I have no way to check.

[playerlin]

Yeah, I use DRD SVN Build.

r297-r300 still use FMOXEX.DLL v4.20.6. And still crashed like r296.

[Enjay]

OK, I just updated to FMODEx 4.22.04 and rebuilt r300. You can get it off the DRD SVN server if you fancy giving it a go.

[playerlin]

OK, I just updated to FMODEx 4.22.04 and rebuilt r300. You can get it off the DRD SVN server if you fancy giving it a go.

*Sigh*

It still crashed...



EDIT : I found the problem source...

in my old ini :

Code: Select all

[GlobalSettings]
.
.
.
opl_onechip=true
.
.
.
.

I change that to "opl_onechip=false" and my GZDoom is no longer crash.

It doesn't happens on Zdoom r1418 and r1424M.
(I only do "opl_onechip=true", maybe that isn't matter...)

Damn, I should do ini cvars check early... *doh*

[Rachael]

hmmm... Setting opl_onechip=true on my computer doesn't crash anything, it may be your hardware or drivers causing the problem. There's a lot of really crappy drivers out there.

[playerlin]

hmmm... Setting opl_onechip=true on my computer doesn't crash anything, it may be your hardware or drivers causing the problem. There's a lot of really crappy drivers out there.

I'll try update the onboard sound driver and check if it still crash.

EDIT : *Sigh* It still crash even I update to Realtek's latest driver...
I don't get it...or it's OS related problem...

I just curious what changes in r296... because it crashed after r296 builds.

And why ZDoom doesn't crash even I set "opl_onechip=true"...
(Like I said on my previous post, ZDoom r1418 and the latest build r1424M are works fine. It's so weird...)

[Enjay]

Changes in r296

Code: Select all

Update to ZDoom r1369:

- fixed some issues with P_FindFloorCeiling's coordinate processing.
- added a new compatmode CVAR which allows setting some generic compatibility 
  flag combinations:
  Doom: sets the options needed to make most Doom.exe compatible map play without
  errors.
  Doom (strict): Same as above but sets a few more options. Please note that this
  does not mean full Doom.exe behavior emulation.
  Boom: Sets all options that consider differences between ZDoom and Boom.
  ZDoom 2.0.63: Sets only the COMPATF_SOUNDTARGET option which is needed for
  many older ZDoom maps.
- added new COMPAT_CROSSDROPOFF option to block monsters from being pushed over
  dropoffs by damage kickback.
- fixed: AFastProjectile::Tick must call Effect only 8 times per tic, regardless
  of the amount of steps taken.
- fixed: momentum checks in AFastProjectile did not use absolute values.
- Restored the rhythm section to fmopl.cpp and made some slight updates from
  version 0.72 of MAME's fmopl.c. Also refactored CalcVoice so that the
  original MAME structure is more visible.
- Removed the SoundChans bitfield from AActor, since it seems there are race
  conditions I don't fully understand where it simply doesn't work.
- Removed BaseTime initialization from sdl/i_system.cpp as per Chris's
  recommendation.

Looks like all those changes come from the update to a newer revision of Zdoom, but there is certainly some sound related stuff in there. Have you tried Zdoom recently?

[playerlin]

Looks like all those changes come from the update to a newer revision of Zdoom, but there is certainly some sound related stuff in there. Have you tried Zdoom recently?

Weird, if I just use my GZDoom's ini in ZDoom, and ZDoom will crashed like GZDoom whatever r1388 or r1424M or any builds on drdteam svn server...

If I just killed my (GZDoom) ini let ZDoom re-creat new ini, then change the line "opl_onechip=" to true, and it works fine.

What the hell...?
Maybe my ini screwed up...or something else...

[playerlin]

Ok... after some test with my old and GZDoom's default ini setting.
I make a copy of my old ini and clear all entries in [GlobalSettings] then let GZDoom recreate those CVARs, then I do one-by-one testing.

Now I found the real crash source.

Code: Select all

.
.
.
snd_mididevice=-3
.
.
.

GZDoom (r302)'s default setting is -1 and I change it to -1 in my old ini then my GZDoom REALLY doesn't crash anymore.
Now this report can close now!

What the CVAR(snd_mididevice) mean? and why it crash with that value?

EDIT : Ok, I know what that is.
snd_mididevice = -1 -> using FMOD
snd_mididevice = -3 -> using OPL Emulate

Now it looks like if I use OPL Emulate and set "opl_onechip" to true will cause ZDoom/GZDoom crashed. Is it normal?

[Graf Zahl]

Fixed.

When opl_onechip was set the second chip was never initialized, not even to NULL so it crashed with an invalid pointer access.

There's just one thing about this report that made me think whether it would make sense to close this bug forum and make it a subforum of ZDoom's. This was clearly a ZDoom bug but since it only was reported here Randy never saw it and couldn't act on it.

[playerlin]

There's just one thing about this report that made me think whether it would make sense to close this bug forum and make it a subforum of ZDoom's. This was clearly a ZDoom bug but since it only was reported here Randy never saw it and couldn't act on it.

I feel shame now because I even can't find this bug is cause by ZDoom.

I think since GZDoom is based on ZDoom, why not just made two programs both using one "Bug Report forum"(maybe Feature Suggestions forum too)...but maybe it just not that easy...

[Rachael]

It would all be up to randy. If that happens, though, I'm leaving these forums here for archival purposes, at least until the board is transferred to phpBB3.

It wouldn't hurt for our good friend to come by every once in a while, though.