[Helixhorned]

LeoD, on 11 May 2013 - 01:10 PM, said:

Didn't r3188 fix that first zoom issue?

These are distinct crashes as far as I can see. The one from r3188 was due to a division where the result didn't fit in an int32, and was in the polygon clipping code. This one seems to appear because of an out of bounds access in the horizontal line texture mapping C function, but not for me.

[fgsfds]

Mapster crashes when I press F on a floor right after mapster and map loading. If I go 3d and then back to 2d, everything's ok. Was broken in 3118.

Attached File(s)

•  mapster32111.log (764bytes)
  Number of downloads: 632

[Helixhorned]

fgsfds, on 29 May 2013 - 09:25 AM, said:

Mapster crashes when I press F on a floor right after mapster and map loading. If I go 3d and then back to 2d, everything's ok.

Thanks for the bug report! Fixed in r3824.

Quote

Was broken in 3118.

I don't think this commit or the couple preceding ones are to blame, it only may have made the existing bug manifest itself in your case. The problem was in code written by me.

[LeoD]

Maybe related to CBP4, occurs sporadically with different EDuke32 versions when trying to reload after dying.
 eduke32.crash.log (2.31K)
Number of downloads: 616
 eduke32.log (13.05K)
Number of downloads: 469

[Zaxtor]

I soo rarely crash.

I usually crash once per 1-3 years.

Without counting negligence from "too many sprites spawned"
I usually fix that fast by turning 10 sprites into 1. Such as bridges etc.

In the old days when Duke was in dos.
I had more crash.

One doing this annoying BRAKAKAKKAAKAKAKAKAKAAKAKAK sound.

[Helixhorned]

LeoD, on 06 October 2014 - 10:47 AM, said:

Maybe related to CBP4, occurs sporadically with different EDuke32 versions when trying to reload after dying.

Yeah, that's expected from these corruptions:

#10: WALL[6497].NEXTWALL=7200 out of .NEXTSECTOR=856's bounds [7204 .. 7231]
 ?? suggest making wall 6497 white
#11: WALL[8104].NEXTWALL=6791 out of .NEXTSECTOR=788's bounds [6375 .. 6384]
   suggest setting wall[8104].nextsector to 833
 ?? suggest making wall 8104 white

Solution: corruptcheck tryfix ??, followed by making the white line red again, e.g. by left-clicking at its upper vertex.

[LeoD]

Helixhorned, on 13 December 2014 - 02:46 PM, said:

Yeah, that's expected from these corruptions:

#10: WALL[6497].NEXTWALL=7200 out of .NEXTSECTOR=856's bounds [7204 .. 7231]
 ?? suggest making wall 6497 white
#11: WALL[8104].NEXTWALL=6791 out of .NEXTSECTOR=788's bounds [6375 .. 6384]
   suggest setting wall[8104].nextsector to 833
 ?? suggest making wall 8104 white

Solution: corruptcheck tryfix ??, followed by making the white line red again, e.g. by left-clicking at its upper vertex.

I don't even know the difference. But some of the CBP4 mappers are still around. Maybe one of them can make an 'official' fix.

[LeoD]

Crash on startup:
 eduke32.log (1.15K)
Number of downloads: 480
 eduke32.crash.log (4.53K)
Number of downloads: 510

[Hendricks266]

That looks like an exception raised in a system call that ebacktrace just happens to catch. Does pressing any of the three buttons in the dialog box that comes up allow the game to continue? If not, try renaming the ebacktrace DLL.

[LeoD]

Hendricks266, on 21 December 2014 - 01:51 PM, said:

That looks like an exception raised in a system call that ebacktrace just happens to catch. Does pressing any of the three buttons in the dialog box that comes up allow the game to continue? If not, try renaming the ebacktrace DLL.

Quit and Continue bail out, Ignore pops up more assertions. Renaming ebacktrace1-64.dll seems to let it run normally.
 eduke32.log (1.1K)
Number of downloads: 481  eduke32.crash.log (4.86K)
Number of downloads: 502

Seems to me some machine-dependent issues have been introduced lately. I've 'confiscated' my dad's laptop currently. No issues on his PC. And the autoload breakage I reported elsewhere some time ago doesn't happen on his hardware, but on my PC at home.

[Zaxtor]

Latest duke still crash and or any eduke32 after the 8/31/2014.
When I play/test my mod.
It crashes after the intro clip.

Isn't the intro clip causing the crash.
When I (Disable) the intro clip even its sounds it still crash.
So and again the LOGO.IVF is innocent, doesn't cause crash.

So using the 8/31/2014 or below works fine.
is only after the 8/31/2014 the crashes starts as soon you skip or finished watching the intro clip.
latest mapster works fine.


Eduke.log incase u need.


PS
I have no clue if the _errorLineNum: 0, g_tw: 0 is the cause of the crash.
My older duke doesn't show that.

Attached File(s)

•  eduke32.log (3.63K)
  Number of downloads: 462

[Hendricks266]

Is there an eduke32.crash.log?

[Zaxtor]

Hendricks266, on 26 December 2014 - 10:58 PM, said:

Is there an eduke32.crash.log?

I don't have one.
It doesn't make any.
I searched.
Even looked carefully.
none.

Only Eduke32.log

[LeoD]

Zaxtor, on 26 December 2014 - 11:07 PM, said:

Only Eduke32.log

Silly question maybe, but are you actually running a debug executable? I'm missing the "polymost_glreset()" line[s] in your eduke32.log.

[Zaxtor]

LeoD, on 27 December 2014 - 04:15 AM, said:

Silly question maybe, but are you actually running a debug executable? I'm missing the "polymost_glreset()" line[s] in your eduke32.log.

I don't run the debug.
I run the standard one.
Cus the debug (undo) the window thingie things from the earlier levels.
I think it does.

[LeoD]

Zaxtor, on 27 December 2014 - 06:59 AM, said:

Cus the debug (undo) the window thingie things from the earlier levels.
I think it does.

No idea what that means.

Zaxtor, on 27 December 2014 - 06:59 AM, said:

I don't run the debug.
I run the standard one.

Only the debug executable (+ ebacktrace[-64].dll) can create a crash log which may help the devs to figure out your issue.

[Zaxtor]

LeoD, on 27 December 2014 - 07:06 AM, said:

No idea what that means.

Only the debug executable (+ ebacktrace[-64].dll) can create a crash log which may help the devs to figure out your issue.

That thing people used to do.
You know in Bedrone, Oblivion, that window glitch thing when you make a 1sided window from using a bug.

I'll try the debug thing.

[Zaxtor]

Works fine with Duke debug.

[Helixhorned]

Zaxtor, on 26 December 2014 - 09:33 PM, said:

Latest duke still crash and or any eduke32 after the 8/31/2014.

The CON translation log shows several type errors.

GAME.CON: In actor `STAINLESSSTEEL_ORB_A':
GAME.CON:56435: warning: expected ai, found move.
GAME.CON: At top level:
GAME.CON:61957: warning: expected action, found move.
GAME.CON:61959: warning: expected define, found action.
(...)
GAME.CON: At top level:
GAME.CON:83954: warning: expected action, found move.
GAME.CON:84205: warning: expected action, found move.

Right now, they are warnings, but I think they should be hard errors. Semantically, passing a different type of composite (action, move, ai) than the expected one makes no sense; likewise for passing a composite where a define was expected. Operationally, I think that they should not cause crashes, but I haven't look deep enough. In any case, this is the first issue to address on your part.

If the crash persists after fixing them, you can PM me the CON files if you like. I promise to keep them confidential (and delete them afterwards if you wish).

[Zaxtor]

Helixhorned, on 28 December 2014 - 10:38 AM, said:

The CON translation log shows several type errors.

GAME.CON: In actor `STAINLESSSTEEL_ORB_A':
GAME.CON:56435: warning: expected ai, found move.
GAME.CON: At top level:
GAME.CON:61957: warning: expected action, found move.
GAME.CON:61959: warning: expected define, found action.
(...)
GAME.CON: At top level:
GAME.CON:83954: warning: expected action, found move.
GAME.CON:84205: warning: expected action, found move.

Right now, they are warnings, but I think they should be hard errors. Semantically, passing a different type of composite (action, move, ai) than the expected one makes no sense; likewise for passing a composite where a define was expected. Operationally, I think that they should not cause crashes, but I haven't look deep enough. In any case, this is the first issue to address on your part.

If the crash persists after fixing them, you can PM me the CON files if you like. I promise to keep them confidential (and delete them afterwards if you wish).

Usually warnings are harmless.
Errors are the one that hurts.

Duke3d.debug works fine.
Duke above the date I mentioned crashes.

I get the "the _errorLineNum: 0, g_tw: 0 "
Older dukes doesn't give that.


I can try to fix these warnings.

[Zaxtor]

Fixed all the listed, still crashes
I'll send u file.

[Helixhorned]

r4871 said:

sounds.c: don't crash S_PlayMusic() if passed null pointer for 'fn'.

This may happen if no title/end music is defined from CON.
Thanks to Zaxtor for the bug report.

[Zaxtor]

np

[Darkus]

EDuke32 crashes when I quit the game.
I first thought that quit the game when you're dead always crashes, but it seems to happen randomly.

 eduke32.log (1.36K)
Number of downloads: 394

 eduke32.crash.log (3.27K)
Number of downloads: 748

[Helixhorned]

Darkus, on 29 December 2014 - 09:13 AM, said:

EDuke32 crashes when I quit the game.
I first thought that quit the game when you're dead always crashes, but it seems to happen randomly.

Are you using custom DEF files, specifically, do they contain a 'sound' definition? The eduke32.log file you posted suggests you're not using any DEFs though.

[Technical info follows.]
The 'sound' token from DEF is the only case how g_sounds[].filename1 can become non-null. If this is the case, this suggests that it may be aliased to other g_sounds[].filename or g_sounds[].filename1. (This should never happen though, AFAICS.) Otherwise, this suggests general memory corruption. In any case, this is disquieting.

[Darkus]

Helixhorned, on 30 December 2014 - 12:51 PM, said:

Are you using custom DEF files, specifically, do they contain a 'sound' definition? The eduke32.log file you posted suggests you're not using any DEFs though.

No, I have not used any DEF files, just the original game, without any replacements.

[Robman]

Anyone have an idea why the following happens? .. I have a large map that contains a huge outdoor area with pretty good detail. I have certain areas of the map and certain ways I turn the view of the player and the map will crash using SWP 4.3.2. Redux does not seem to crash with the same map and conditions. What's going on here?

[Hendricks266]

Robman, on 06 January 2015 - 02:37 PM, said:

the map will crash using SWP 4.3.2

PM me your map and I'll see if I can debug. I already have an MP bugfix staged for 4.3.3 beta 3.

[Micky C]

Been experiencing some crashing with the AMC TC. Finally downloaded the latest debug eduke32 and caught the bastard red-handed. I hope this is useful;

log: http://pastebin.com/DqzTwNPU

crashlog: http://pastebin.com/Yf6Ujg64

Edit: Btw I'm also getting that "crash on exiting" thing, where I get a message that "eduke32 has stopped responding".

[LeoD]

Sound Replay Regression

As of r4616, EDuke32 freezes when trying to play certain sounds:
- goaway.voc from Noctis Labyrinthus Revisited / DN64 Revisited
- lca.wav from Lights, Camera, Action from Duke Nukem Eternity's dne01.map

Attached File(s)

•  ReplayFreezeFiles.zip (847.04K)
  Number of downloads: 380