User Tag List

Page 1 of 3 1 2 3 LastLast
Results 1 to 10 of 22

Thread: Yuurei: Utterly Bizarre Crash on 2.50.x Tree Builds

  1. #1
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%

    Verified Bug Yuurei: Utterly Bizarre Crash on 2.50.x Tree Builds

    This quest, crashes when scrolling on all builds of the 2.50.x branch. It did not seem to crash on 2.50.3RC1, but it sure did on a clean build of the repo from 4-Dec-16.

    This seems to happen in conjunction with super-fast scrolling, and some mad method that the quest creator is using to handle adding and removing enemies using arrays.

    From Aevin:
    This is probably related to my enemy spawn script. Enemies in Yuurei use a custom spawn system that works by storing the number of enemies remaining on each screen in an array, then spawning them based on a number of checks triggered by the screen scrolling. It ditches any enemies that normally spawn by moving them offscreen, then spawns the correct number of npcs from the array. The opening screen's "remaining enemies" number should always be zero with this method, though, so I'm confused why anything would ever try to spawn there ...
    Would someone do an msys build of the 2.50.x repo tree, and verify that this happens for them?

    We tested it on this build: http://timelord.insomnia247.nl/zc/zc...0.3_Beta_2.zip

    This was built from the 2.50.x tree on 4-Dec-16.

    It does not happen in 2.50.2, and from what we could tell, it did not happen on 2.50.3RC1, but it did happen on a build fro the tree. That's why I'm asking for a separate confirmation on builds of that tree. Perhaps there is some change that is in 2.50.3 that was not integrated properly in the tree, such as the parser array changes that Saffith made. Anything like that should have been corrected when we rebuild the flex files, yet this bug is carried through the entirety of our fork like a contagion.

    All you need to to create this crash, is move one screen in any direction from the start, then go back tot he starting screen. That has seemed to randomly crash the game. The quest is also generating this error, in conjunction with its scripts, and autoghost, and probably npc arrays.


  2. #2
    Banned
    Join Date
    May 2015
    Posts
    141
    Mentioned
    34 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    667
    Level
    9
    vBActivity - Bars
    Lv. Percent
    14.48%
    I only tested the start screen crash by returning from the screen to the right. I never got crashes from scrolling right, only scrolling left. In fact, moving left onto most screens either causes noticeable lag or outright crashes, while scrolling right has no problems. Also, guaranteed crash when moving up or down a screen. This bug also only applies to the latest version of Yuurei: the original release does not crash.

  3. #3
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,024
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.05%
    Is "smart scrolling" enabled in this quest by any chance?

  4. #4
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    Quote Originally Posted by DarkDragon View Post
    Is "smart scrolling" enabled in this quest by any chance?
    I'm not sure. I'll check tomorrow, but based on what Aevin has to say, the problem can't just be related to scrolling:

    Well, consider me confused. It isn't my spawn system; I commented out the entire thing and still got the crash. Then, I turned on "view ffc scripts" through the cheat menu, and ... Right before the crash, I saw that it had begun running the script for one of my ghosted enemies; the script 36 listed in the error log.
    *
    There's nothing that should be running that script, and it certainly doesn't run on any of the previous ZC versions. I really don't know what could be causing this. I'm really doing nothing terribly complicated on my end outside of the spawn system, which is now fully disabled. I even searched for every instance of running ffc scripts in my script file, and that particular script is never once called outside of the specific enemy spawning on certain screens. But the enemy doesn't appear on any of those screens, and it's that specific script that causes the crash on any of the other screens, too, none of which have the enemy.
    *
    It seems to me that ZC is just randomly calling this script, then crashing because there's no enemy associated with it.
    *
    Edit: Looking closer frame by frame reveals that as soon as scrolling begins, it calls a series of ffc scripts. I can't see any rhyme or reason to the ones it calls, but they are consistent depending on which screen I scroll to. For example, going right from the start doesn't crash, but going back left runs three separate ffc scripts in the same slot in quick succession, ending with script 36 before the error. However, cheating and going up through the wall runs a different script, then crashes. The other odd thing is that there are gaps before the scripts that cause the crash, as if there are "blank" scripts being called from further down the script list. For example ... My opening screen has a "ContinuePoint" script that runs at screen init. What I see when walking back left onto the screen is this:
    *
    ContinuePoint
    -----------
    -----------
    ultimadome ->SandCroc->Earth Elemental (in quick succession)
    *
    These blank slots (totally blank, not actually dotted lines) also happen when walking up through the wall, but the script that causes the crash there is different.
    *
    Not sure what's going on here ...
    That seems to indicate that the ffengine is losing its mind, from something. it could be related to the parser changes that @Saffith implemented. I'm only guessing at present, as I need to run some tests, but perhaps if a quest has more than N ffcs loaded into slots, it isn't properly storing the datum. I truly have no out-of-hand explanation for this; which is why I would like anyone else to compile 2.50.x from 4-Dec-16, as I want to rule out some bizarre compiler issue on our end, using the latest gcc via MSYS.

    If gcc is mucking something up terribly, then clearly it is not a viable option and this needs to be addressed.

  5. #5
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,429
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.42%
    Code:
    (gdb) print tmpscr->ffscript
    $6 = {0 <repeats 14 times>, 4096, 39, 0 <repeats 16 times>}
    Well, that's not good. But in ZQuest, they're all 0, as expected. Hm...

    Code:
    Hardware watchpoint 1: tmpscr->ffscript[14]
    
    Old value = 0
    New value = 4096
    set_register (arg=13, value=2560000) at src/ffscript.cpp:2912
    2912	        break;
    (gdb) bt
    #0  set_register (arg=13, value=2560000) at src/ffscript.cpp:2912
    #1  0x0806c28d in do_set (v=false, whichFFC=255 '\377')
        at src/ffscript.cpp:4857
    #2  0x08072031 in run_script (type=0 '\000', script=1, i=255 '\377')
        at src/ffscript.cpp:6724
    #3  0x080735c9 in ZScriptVersion::RunScript (type=0 '\000', script=1, 
        i=255 '\377') at src/zscriptversion.h:35
    #4  0x081135b3 in LinkClass::run_scrolling_script (this=0x8877d80 <Link>, 
        scrolldir=2, cx=17, sx=256, sy=0, end_frames=false) at src/link.cpp:12204
    #5  0x081c3248 in ZScriptVersion::ScrollingScript (scrolldir=2, cx=17, sx=256, 
        sy=0, end_frames=false) at src/zscriptversion.cpp:16
    #6  0x0811f257 in ZScriptVersion::RunScrollingScript (scrolldir=2, cx=17, 
        sx=256, sy=0, end_frames=false) at src/zscriptversion.h:40
    #7  0x0811474e in LinkClass::scrollscr (this=0x8877d80 <Link>, scrolldir=2, 
        destscr=-1, destdmap=-1) at src/link.cpp:12577
    #8  0x08112ae1 in LinkClass::checkscroll (this=0x8877d80 <Link>)
        at src/link.cpp:11935
    #9  0x080e8c8d in LinkClass::animate (this=0x8877d80 <Link>)
        at src/link.cpp:4266
    #10 0x081bd6f8 in game_loop () at src/zelda.cpp:2359
    #11 0x081c0630 in main (argc=4, argv=0xffffd234) at src/zelda.cpp:3589
    It's coming from the scrolling script. It could be a script error that ZC isn't catching. But it looks like it's actually setting ffc->X?

    Code:
    (gdb) print ri->ffcref
    $20 = 255 '\377'
    Oh, there we go. It's trying to set ffc->X for FFC #256. That'll do it.
    Last edited by Saffith; 01-06-2017 at 01:34 PM.

  6. #6
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    Quote Originally Posted by Saffith View Post
    Code:
    (gdb) print tmpscr->ffscript
    $6 = {0 <repeats 14 times>, 4096, 39, 0 <repeats 16 times>}
    Well, that's not good. But in ZQuest, they're all 0, as expected. Hm...

    Code:
    Hardware watchpoint 1: tmpscr->ffscript[14]
    
    Old value = 0
    New value = 4096
    set_register (arg=13, value=2560000) at src/ffscript.cpp:2912
    2912	        break;
    (gdb) bt
    #0  set_register (arg=13, value=2560000) at src/ffscript.cpp:2912
    #1  0x0806c28d in do_set (v=false, whichFFC=255 '\377')
        at src/ffscript.cpp:4857
    #2  0x08072031 in run_script (type=0 '\000', script=1, i=255 '\377')
        at src/ffscript.cpp:6724
    #3  0x080735c9 in ZScriptVersion::RunScript (type=0 '\000', script=1, 
        i=255 '\377') at src/zscriptversion.h:35
    #4  0x081135b3 in LinkClass::run_scrolling_script (this=0x8877d80 <Link>, 
        scrolldir=2, cx=17, sx=256, sy=0, end_frames=false) at src/link.cpp:12204
    #5  0x081c3248 in ZScriptVersion::ScrollingScript (scrolldir=2, cx=17, sx=256, 
        sy=0, end_frames=false) at src/zscriptversion.cpp:16
    #6  0x0811f257 in ZScriptVersion::RunScrollingScript (scrolldir=2, cx=17, 
        sx=256, sy=0, end_frames=false) at src/zscriptversion.h:40
    #7  0x0811474e in LinkClass::scrollscr (this=0x8877d80 <Link>, scrolldir=2, 
        destscr=-1, destdmap=-1) at src/link.cpp:12577
    #8  0x08112ae1 in LinkClass::checkscroll (this=0x8877d80 <Link>)
        at src/link.cpp:11935
    #9  0x080e8c8d in LinkClass::animate (this=0x8877d80 <Link>)
        at src/link.cpp:4266
    #10 0x081bd6f8 in game_loop () at src/zelda.cpp:2359
    #11 0x081c0630 in main (argc=4, argv=0xffffd234) at src/zelda.cpp:3589
    It's coming from the scrolling script. It could be a script error that ZC isn't catching. But it looks like it's actually setting ffc->X?

    Code:
    (gdb) print ri->ffcref
    $20 = 255 '\377'
    Oh, there we go. It's trying to set ffc->X for FFC #256. That'll do it.
    Let me know where you fix this source-side please. (Further, when was this issue introduced?)

    Or are you saying that this is from the quest script, and not run_scrolling_script in ZC?

  7. #7
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,429
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.42%
    Yes, it's the quest script, unless the refInfo itself is getting corrupted somehow. I'll have to check with Aevin.

    The issue of ZC failing to validate the FFC has always been there. It manifests differently now because script data was rearranged for 2.50.3. Previously, it would have been corrupting something else, most likely ffc->Misc, and would probably be harmless.

  8. #8
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    Quote Originally Posted by Saffith View Post
    Yes, it's the quest script, unless the refInfo itself is getting corrupted somehow. I'll have to check with Aevin.

    The issue of ZC failing to validate the FFC has always been there. It manifests differently now because script data was rearranged for 2.50.3. Previously, it would have been corrupting something else, most likely ffc->Misc, and would probably be harmless.
    Oh, lovely.

    I was mostly surprised, because the official 2.50.3RC1 release didn't seem to do it. My main concern was that the builds based on the 2.50.x tree, did, and that somehow when we compiled those, values were being stored improperly, corrupted as a result. It would be interesting to see what this was doing on 2.50.2 that its effects weren't noticed.

    What did you use to generate that debug output stream? Was that ffdebug.cpp's output, or something else? Would be handy to have.

    Thank you for figuring this out.

  9. #9
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,429
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.42%
    That's GDB, the GNU debugger. I think the Windows version is included with MinGW.

  10. #10
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    Quote Originally Posted by Saffith View Post
    That's GDB, the GNU debugger. I think the Windows version is included with MinGW.
    Sigh, same quest, new issue:

    http://www.purezc.net/forums/index.p...2#entry1013450

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social