Vincehood Posted January 18, 2017 Share Posted January 18, 2017 Hello, I have noticed that when I introduce some comments in (working) code using REM or ', I easily end-up in a situation where the compilation fails with an Intysmap.exe error window (see attachment). Any clue on what is wrong? Thanks /Vincent Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 18, 2017 Share Posted January 18, 2017 Hello, I have noticed that when I introduce some comments in (working) code using REM or ', I easily end-up in a situation where the compilation fails with an Intysmap.exe error window (see attachment). Any clue on what is wrong? Thanks /Vincent Can you provide an example of a line with a comment that causes the error? Better yet, can you provide a short sample program that fails? I have encountered this problem myself when testing the SDK with the latest version of IntyBASIC against the example programs, but I never found out what causes it. dZ. Quote Link to comment Share on other sites More sharing options...
Vincehood Posted January 18, 2017 Author Share Posted January 18, 2017 (edited) Hello, I include the complete sample I have been working on the last few days (a controllable half animated running man with some minimalistic collision detection). I have got the issue again but this time I cannot trace to a specific thing since I changed several things at the same time. Note that despite what I wrote earlier the compilation seems to succeed. I am getting a ROM that I can execute. So the error does not seem to be a blocking one at least. Thanks /Vincent Tron3.bas title.bas Edited January 18, 2017 by Vincehood Quote Link to comment Share on other sites More sharing options...
Vincehood Posted January 18, 2017 Author Share Posted January 18, 2017 One more thing: I just noticed that the error disappears when I comment away "INCLUDE title.bas" /V Quote Link to comment Share on other sites More sharing options...
fsuinnc Posted January 18, 2017 Share Posted January 18, 2017 I have had the IntySmap.exe window pop up a lot since the new SDK came out. I have not noticed that it has anything to do with comments in the code but it might be because I wasn't paying attention to that. The thing I find odd is that when the message window appears and I let it run its course and then close it when it is done, I just do another IntyBuild and it works. unlike, Vincehood I do not believe the compilation is complete but I will need to check that. This has started just since the new SDK and I also started using the TITLE.BAS so I am not sure which one might be involved or both. If there are problems finding the issue I will try and recreate some of my older stuff without title.bas and see if I can help narrow it down. Maybe there are more line being concatenated using the \ that I am not aware of. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 18, 2017 Share Posted January 18, 2017 During testing of the SDK, the error manifested on a single example program. It occurred the same whether I used the SDK tools or call the binaries directly. Also, the example was not using the new Title.bas file, so it has nothing to do with that. It appears to be related to the latest version of intyBASIC or IntySMap, both of which were updated in the latest SDK. The IntySMap tool creates a map between IntyBASIC variables and the Assembler's symbol table and exports this to the debugger. The ultimate effect is that you can refer to variables, labels, and procedures in the debugger by name rather than having to figure out their memory address. This is useful for setting breakpoints and watches. This mapping does not affect compilation, and it is a separate step in the process. The SDK build tools try to be smart and call the underlying tools in sequence, first the compiler, then IntySMap, and finally the assembler; all so that you don't have to do this manually yourself. IntySMap is very useful and essential if you use the debugger, so the automatic chain of tools is very convenient. If for some reason IntySMap fails (like is happening to you), it does not affect the build process. It may impair your ability to view or access variables and labels by name in the debugger, though. All that said, I'll take a look at the program attached to try to find out why it is failing, and see of we can work-around it. However, ultimately, it may require nanochess' attention gives to see what's going on under the covers. dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 18, 2017 Share Posted January 18, 2017 I just checked my notes and indeed it was "game2.bas," which does not use the new TITLE.BAS file, that causes the exact same IntySMap error when building the binaries. Indeed, if you try to build it, you'll get the same error. I'll compare your program to that one and to a working one to see what is common and different amongst them. Also, it is important for me to point out that such an error did not occur with the new SDK until I upgraded the compiler and IntySMap binaries. Keep in mind that the SDK has been completed since Summer 2016, and was tested successfully then. What transpired from then to the actual release several months later were minor adjustments in the documentation, additional example programs, lots of procrastination, and complete new versions of the compiler binaries. dZ. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted January 18, 2017 Share Posted January 18, 2017 In case anybody wants to look at it, the source code for IntySmap is in the contrib folder of the IntyBASIC release. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 18, 2017 Share Posted January 18, 2017 In case anybody wants to look at it, the source code for IntySmap is in the contrib folder of the IntyBASIC release. It's in the SDK too. Quote Link to comment Share on other sites More sharing options...
Vincehood Posted January 19, 2017 Author Share Posted January 19, 2017 Hello, That has probably no relation with the issue I initially reported and is most likely due to my bad programmning, I have however noticed that the code I shared is eventually dying under execution in some situations. Each time the running man is moved outside the screen, the program re-restarts from the initial position (this was intentional). If you do that around 15 to 25 times in a row, the game will simply exit. I don't know why but I have not investigated yet. I suspect that I have been careless somewhere. /V Quote Link to comment Share on other sites More sharing options...
catsfolly Posted January 19, 2017 Share Posted January 19, 2017 (edited) HelloThe problem is that you can't just goto another part of your code from inside a procedure.Calling a procedure pushes its return address on the stack. You must return from the procedure or the stack over flows.Set a flag in the procedure and check it after you return.Catsfolly Edit - In detail, I would suggest making these changes to your code: Rem in the variables Spriteframe=0 aCollisionOccured=0 rem in the main loop Gosub CheckCollisions if (aCollisionOccured > 0 ) then goto restart rem in the procedure CheckCollisions: PROCEDURE IF COL0 AND HIT_BACKGROUND THEN aCollisionOccured = 1 ELSE aCollisionOccured = 0 END Edited January 20, 2017 by catsfolly 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 19, 2017 Share Posted January 19, 2017 I've been playing with your code to see what is causing IntySMap to fail, and I've narrowed it down to a couple of lines. It is so weird, I can't for the life of me figure out what the heck is going on!! In this section: restart: WAIT ' INIT GAME VARIABLES X1=80 Y1=56 Counter=0 Spriteframe=0 CONST SOLID= ($5f * + 4 ' DRAW SCREEN for i = 0 to 20 poke BACKTAB_ADDR + i, SOLID poke BACKTAB_ADDR + (20 * 11) + i, SOLID next for #i = 20 to (20 * 11) step 20 poke BACKTAB_ADDR + #i, SOLID poke BACKTAB_ADDR + #i + 19, SOLID next If I comment any of the following variable definitions: X1=80 Y1=56 Counter=0 Spriteframe=0 IntyBASIC will work. Just that. Commenting any of of those lines. Could it be a buffer or stack overflow in IntySMap? Too many variables blowing an array? Someone will have to debug it. Also, it appears to exit abnormally because the test for an error code "1" is not being honoured after it, and the source code suggests that all exceptions exit with error code "1". I know that if I run IntySBASIC from the command-line directly, I get a huge stream of warnings, but it doesn't crash. However, this output (STDERR, I suppose) is not manifested when executing using INTYBUILD. Perhaps it's the batch script processor has a buffer overflow? -dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 19, 2017 Share Posted January 19, 2017 The exception given by Windows is 0xC0000005, which apparently is a Windows Access Violation when writing to memory. The most confusing thing to me is why it only manifests when I run the IntySMap program via a Batch Script but not when run directly from the console command-line. Obviously something is different within the script. I am not an expert in Batch Scripting, so any help would be appreciated. I have traced it down to calling the binary via a variable vs. explicitly by name, for instance: SET SMAP=IntySmap.exe SET BINDIR=bin SET FNAME=%~n1 %SMAP% "%BINDIR%\%FNAME%.map" versus... SET SMAP=IntySmap.exe SET BINDIR=bin SET FNAME=%~n1 IntySMap.exe "%BINDIR%\%FNAME%.map" The former triggers the Windows exception, while the latter injects a bunch of warnings from STDERR into the console's output and doesn't crash. The idea of defining the variables for the binaries was from an earlier version of the SDK that did not set the execution PATH in the environment, and had to explicitly state the full path to each executable. That is no longer the case, so I can certainly change this in the next version of the SDK. However, I would like to understand what is going on, and why it is crashing, and why I am unable to capture STDERR into a file (even with redirection) when executed using the variable. -dZ. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted January 19, 2017 Share Posted January 19, 2017 Does using the delayed expansion "!" (instead of "%") operator help? e.g. !SMAP! "..." Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 19, 2017 Share Posted January 19, 2017 Does using the delayed expansion "!" (instead of "%") operator help? e.g. !SMAP! "..." Good idea! but alas, no. -dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 19, 2017 Share Posted January 19, 2017 So, one strange observation is that, although it seems to be related to the Batch Script processing, it is an IntySMap Windows Access Violation. The page I linked to suggested that it could be due to the new Data Execution Prevention (DEP) mechanisms implemented in XP SP 2 (and later Windows versions). What could the Batch environment be changing that induces IntySMap to violate DEP policy? -dZ. Quote Link to comment Share on other sites More sharing options...
carlsson Posted January 19, 2017 Share Posted January 19, 2017 (edited) For what it is worth, I recompiled five of my different IntyBASIC projects and assembled with the generation of a smap file. Out of those files, 3 made Intysmap crash/hang and 2 passed successfully. I suppose it is a good thing I rarely try source code debugging. Actually it seems quite a bit random if it succeeds, hangs or crashes. One blank line too many or too few can make all the difference, it seems to me. Edit: Your milage may vary, but this file compiles, assembles and smaps (is that a verb?) OK: musicbox-smapok.bas This one, which has one extra blank line after the first six REM lines, makes Intysmap hang on my computer: musicbox-smapfail.bas The tools I'm using: IntyBASIC v1.2.8 as1600 (from jzintv distribution 1.0, dated 2016 - the assembler doesn't seem to specify which version it is?) IntySmap.exe dated August 1, 2015 (dunno if there is a newer/other version) Windows XP Home Edition 32-bit SP3 (Athlon64) with command line prompt I suppose I could try to run the same tools on a newer Windows version or other CPU, in case that is the problem. Edited January 19, 2017 by carlsson Quote Link to comment Share on other sites More sharing options...
carlsson Posted January 19, 2017 Share Posted January 19, 2017 (edited) After spending an hour with IntySmap.c, I believe there is a problem in the function put_remap: void put_remap( int asm_file, int asm_lineno, int bas_file, int bas_lineno ) { /* Usu. iterates 0 or 1 times. I don't care if it iterates 2+ times */ while ( remap_sz[ asm_file ] < asm_lineno ) { int old_sz = remap_sz[ asm_file ], i; int new_sz = remap_sz[ asm_file ] = old_sz ? old_sz * 2 : 1024; remap_tbl[ asm_file ] = realloc ( remap_tbl[ asm_file ], new_sz * sizeof( remap_rec_t ) ); for ( i = old_sz ; i < new_sz ; i++ ) { remap_tbl[ asm_file ][ i ].bas_file = -1; remap_tbl[ asm_file ][ i ].bas_lineno = -1; } } remap_tbl[ asm_file ][ asm_lineno ].bas_file = bas_file; remap_tbl[ asm_file ][ asm_lineno ].bas_lineno = bas_lineno; } I added some debug printf and found that for the very last line, bas_lineno never got initiated. To be honest, I don't fully understand what this line accomplishes, other than setting both new_sz and remap_sz to old_sz*2 in case old_sz is not zero: int new_sz = remap_sz[ asm_file ] = old_sz ? old_sz * 2 : 1024; However, I added another line directly following that line to ensure the initiating loop below goes through every record: new_sz++; After recompiling (using gcc 3.4.5 in an ancient installation of MinGW), IntySmap no longer crashes on either of my programs. If the debugging works properly though, I haven't tried. I'm trying to attach the modified C code and a Windows 32-bit executable. Joe Z or Oscar probably wants to look at this one more time before committing the change for later versions of IntyBASIC. intysmap-gcc.zip Update: Crashes hopefully won't happen, but the smap output looks identical after as1600 and after intysmap, which I'm not sure it should be? Edited January 19, 2017 by carlsson Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 20, 2017 Share Posted January 20, 2017 I added some debug printf and found that for the very last line, bas_lineno never got initiated. Hmm... Strange, I see that it "bas_lineno" was initialized at the top of "process_asm()": void process_asm( int asm_file ) { int bas_file = -1; int asm_lineno = 0, bas_lineno = 0; FILE *f = open_with_path( asm_file ); Then updated whenever a BASIC line number is encountered in the source: // Looks for lines like: // ;[478] CONST SPR22 if ( sscanf( buf, "\t;[%d]", &l ) == 1 ) { bas_lineno = l; continue; } And then submitted as an argument to "put_remap()." Unless you mean that it never changes from zero. That would be a failure in scanning the file. Quote Link to comment Share on other sites More sharing options...
carlsson Posted January 20, 2017 Share Posted January 20, 2017 Well, something weird happened. My debugging indicated it was set to -1 except for the last line, where the value was in the range of 16 million or something like that which to me sounds like random memory access. But more to the point, what does this program do that the as1600 doesn't already do? It seems to me that the IntyBASIC source is mapped to the assembler code already when using the -j argument with as1600. Probably there should be some additional remapping inbetween the files that fixes things the assembler was unable to do, but unless I managed to break it entirely with adding one line of code, the output from as1600 and the modified output from Intysmap look identical? Perhaps an earlier version of as1600 had limited mapping, as this tool was written for the release of IntyBASIC 1.0.0 in 2015, and a newer version of as1600 already does what the tool previously fixed? I'm quite confused, and sure that the other of you have better ideas. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 20, 2017 Share Posted January 20, 2017 Hi, carlsson, Good points. What this program does is attempt to re-map the Assembly listing file to the IntyBASIC source files. The assembler creates a map file that essentially tracks to which line in the source each instruction location maps to. That way, the debugger can show you the exact line from the source (including any comments it may have) at each execution point rather than the more cryptic disassembled instruction. IntySMap modifies the map file to point to the IntyBASIC source files instead to abstract away the assembly source. This is strictly for the debugger, which is fed through some optional command arguments. The IntyBASIC SDK conveniently sets this up for you when you run the INTYDBUG tool. I don't know if this is even necessary any more. When you compared the assembler output to that of IntyBASIC, are you checking the source file or the map file? -dZ. Quote Link to comment Share on other sites More sharing options...
carlsson Posted January 20, 2017 Share Posted January 20, 2017 I ran as1600 -j blahblah.smap -s blahblah.sym -l blahblah.lst and preserved an extra copy of the generated smap file. Then I ran IntySmap blahblah.smap which generated a new smap file. Then I visually compared the two files side by side, and could not find a single line where the output numbers differed. Right now I can't remember if I even ran diff from the Msys prompt. Thus I wonder if I've broken something, or the smap file from as1600 already is good enough for debugging purposes. That will be my next step tonight, actually run jzintv with debugging to see if it picks up the IntyBASIC source somehow. If the two smap files are identical and debugging doesn't work with either, I've broken the IntySmap tool. If the two files are identical and debugging does with any of the two, the extra tool is no longer needed. If the two files really have differences (I'll try a few different IntyBASIC programs to be sure), then everything possibly is as it should. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 20, 2017 Share Posted January 20, 2017 I ran as1600 -j blahblah.smap -s blahblah.sym -l blahblah.lst and preserved an extra copy of the generated smap file. Then I ran IntySmap blahblah.smap which generated a new smap file. Then I visually compared the two files side by side, and could not find a single line where the output numbers differed. Right now I can't remember if I even ran diff from the Msys prompt. Thus I wonder if I've broken something, or the smap file from as1600 already is good enough for debugging purposes. That will be my next step tonight, actually run jzintv with debugging to see if it picks up the IntyBASIC source somehow. If the two smap files are identical and debugging doesn't work with either, I've broken the IntySmap tool. If the two files are identical and debugging does with any of the two, the extra tool is no longer needed. If the two files really have differences (I'll try a few different IntyBASIC programs to be sure), then everything possibly is as it should. Ah I see. It is perfectly possible that the latest version of as1600 covers the mapping for IntyBASIC and that IntySMap is no longer needed. If I may make a suggestion, could you test with the stock version of IntySMap without your modifications and one of the programs that does not cause it to crash? That way we'll know if your changes broke something or IntySMap is truly superfluous. I hope intvnut chimes in with some insight. -dZ. Quote Link to comment Share on other sites More sharing options...
carlsson Posted January 20, 2017 Share Posted January 20, 2017 (edited) Yup, that was the very last thing I tried before going to bed yesterday but I was unable to restore the previously crash free IntyBASIC program to .. a crash free state. Better luck next time. I'll try to download the one I already posted above... perhaps the phase of the moon has any importance too. (I would happily accept "Your Windows XP installation is broken" or "Your computer must have a memory hardware failure" but as it doesn't happen just to me, I doubt it is one of those) Edited January 20, 2017 by carlsson Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 20, 2017 Share Posted January 20, 2017 Yup, that was the very last thing I tried before going to bed yesterday but I was unable to restore the previously crash free IntyBASIC program to .. a crash free state. Better luck next time. I'll try to download the one I already posted above... perhaps the phase of the moon has any importance too. You could try building any of the IntyBASIC SDK examples. The only one that crashes IntySMap is "game2". (I would happily accept "Your Windows XP installation is broken" or "Your computer must have a memory hardware failure" but as it doesn't happen just to me, I doubt it is one of those) I agree with you. I would accept that there is a problem with the SDK, but since all it does is call IntySMap from a batch file in the way it was designed, it seems very strange. To me it is likely that there is an access violation that manifests as a crash due to DEP when executed within the constrained context of a a Command.com script. By the way, thanks for helping debug this problem. dZ. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.