QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Pete on February 04, 2020, 11:20:55 am

Title: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 11:20:55 am
I made a typo in a sub call parameter, which resulted in the variable I intended to use in a mod statement being zero. This should have triggered some kind of error, similar to division by zero, but instead, it just crashed the program after a couple of second delay. You know, the kind of delay where the Windows mouse goes into a flat spin. Hey, maybe some day they'll come up with a Windows Maverick. That system could find it's way out of a flat spin, but I digress. Anyway, something like...

myvariable = 10
PRINT 7 MOD myvariable

That works as intended, but if...

myvariable = 0
PRINT 7 MOD myvariable

... That would probably crash. This line is similar to the line in my code, without going through the sub argument passes, etc. I'd like to test this simplified code line, but I've got too many windows and projects open at the moment.

Maybe this was addressed in a later version. I'm still using 1.3.

Pete
Title: Re: MOD crashed my program!!!
Post by: bplus on February 04, 2020, 11:30:53 am
No crash, it is division by 0
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 12:21:10 pm
That's what it should be, but in my 1.3 version, my more complicated routine just crashes. When I get some windows closed and work finished today, I'll try the code I posted, vs. the actual code in my program. Maybe the example I posted won't crash, and something else in my code is preventing the error message from being activated.

Are you using v 1.3, or a later developer build or the new version?

Pete
Title: Re: MOD crashed my program!!!
Post by: bplus on February 04, 2020, 12:35:04 pm
Hi Pete,

1.3 except to test new commands I find might come in handy, copying Fellippe's examples to a folder for reminders but I don't have any new stuff tested in dev's of 1.3 because some might be rejected or improved for standard issue. Steve's colors and console stuff is all going in?

Did you use 7 mod 0 as argument to parameter, I can see how that would be disastrous! Do I want to test? No, why go looking for trouble? :)
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 02:25:17 pm
Hi Mark,

I just used the 7 MOD 0 as an example. In my routine, the MOD statement is involved in a loop, but the myvariable is always 10 so something like:

CALL example(myvariable)
myvariable = 10

SUB example(myvvvvvariable) ' Oops, this typo will make myvariable an undefined zero value in this sub!
FOR i = 1 to 10
x = i MOD myvariable
NEXT
END SUB

So when I goofed on the typo, not a bad as the example I put up here, I actually just missed a letter in mine, but anyway, same results, a zero division with MOD. It should have thrown a division by zero error, but it didn't. It just crashed the program.

Oh, I should mention that I'm NOT using $CHECKING_OFF or whatever it's called. So that isn't the issue.

I get the "Why go looking for trouble?" 100%. I'll fiddle with this more when I don't have stuff to lose, which just isn't happening anytime soon. I'm in the middle of a 8000 line program, among other website things. I just figured if I posted something now, I wouldn't forget what happened at a later date.

Pete
Title: Re: MOD crashed my program!!!
Post by: Cobalt on February 04, 2020, 02:30:17 pm
mine throws a Division By Zero error at run time. using v1.1 for kicks.
does your program just flat out terminate with no Div by 0 popup?
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 03:50:24 pm
Yep, it just spins for two seconds, and then crashes. No error message.

Pete
Title: Re: MOD crashed my program!!!
Post by: Bert22306 on February 04, 2020, 04:13:47 pm
I tried the first test program your posted, and the one with the subroutine, and with QB64 v1.4, they both flag this division by 0 error.
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 04:29:23 pm
Well it looks like I'll have to take a closer look at this when I close out my projects tonight. I didn't save that code, but I think I can get back to it, give it another try, and see what's up. Maybe I discovered a bug but if so, it's apparently not as straight-forward as the examples I posted.

Pete
Title: Re: MOD crashed my program!!!
Post by: bplus on February 04, 2020, 04:31:40 pm
Hey Pete, the way you have it listed, you don't need the typeo because you set the variable after you call the sub.

OK I looked:
Code: QB64: [Select]
  1. example 7 MOD var
  2.  
  3.  
  4. SUB example (myvariable) ' Oops, this typo will make myvariable an undefined zero value in this sub!
  5.     FOR i = 1 TO 10
  6.         x = i MOD myvariable
  7.     NEXT
  8.  

no crash, just division by 0

I looked some more and can't get it to crash.
Title: Re: MOD crashed my program!!!
Post by: SMcNeill on February 04, 2020, 04:41:22 pm
Yep, it just spins for two seconds, and then crashes. No error message.

Pete

I've tested this with every odd combination I can think of, and I can't reproduce the problem.

Code: [Select]
$CHECKING:OFF
$CONSOLE:ONLY
_DEST _CONSOLE
PRINT 1 MOD 0

Checking on, checking off, print to the console, a file, a normal text screen....  They all toss a "Division by 0" error for me.  DEFINT, DEFLNG, _DEFINE A-Z AS _FLOAT -- none of these make any difference.

Are you certain the MOD statement is causing the issue?  Did your typo change or interact with a different line inside the sub?  When a program just crashes on you, it can be hard sometimes to pinpoint the exact spot where it crashed as you don't have any error reports or line numbers to refer back to. 

If all else fails, share the whole code which glitches out with you and then we'll work on removing sections until we get to the smallest possible batch to try and reproduce the result.  As it is, I don't have a clue what the problem might be.  At this point, my only suggestion would be: Download the 1.4 candidate and see if the problem still persists for you.

It may be that whatever the glitch is, is one that we've already addressed in the last year and fixed, and that's why it's proving impossible for me to replicate it.  I don't know who fixed it, or how it got fixed, but if it is, you're welcome in advance.  ;D
Title: Re: MOD crashed my program!!!
Post by: FellippeHeitor on February 04, 2020, 04:57:31 pm
What OS version again? (If it's been mentioned above I missed it, sorry)
Title: Re: MOD crashed my program!!!
Post by: bplus on February 04, 2020, 05:26:09 pm
What OS version again? (If it's been mentioned above I missed it, sorry)

reply #2 v 1.3
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 05:59:59 pm
Yep 1.3. To be even more specific...

V 1.3 [Revision] Stable from git: 96937f0

Pete
Title: Re: MOD crashed my program!!!
Post by: bplus on February 04, 2020, 06:14:59 pm
Yep 1.3. To be even more specific...

V 1.3 [Revision] Stable from git: 96937f0

Pete

Same as mine, Steve might be right, something else is causing the crash.
Title: Re: MOD crashed my program!!!
Post by: FellippeHeitor on February 04, 2020, 06:43:06 pm
Yep 1.3. To be even more specific...

V 1.3 [Revision] Stable from git: 96937f0

Pete

What *OS* version... Windows 10? XP? 32bit or 64bit?
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 07:57:20 pm
Windows 10 64-bit. Now here's what's weird. I took everything out, except the FOR/NEXT loop where MOD encounters zero, and I do get the appropriate division by zero error. If I put the code beyond the FOR/NEXT loop back in, it crashes instead of giving me the error. I hope to be able to whittle it down in time, to see what exactly in the compiled code is causing this.

Pete
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 08:22:12 pm
Well, I've got other stuff that needs doing, but I got it whittled down to this, so far. It crashes, unless I remove the FOR j = 1 TO tcnt loop.

Note that the reason MOD gets division by zero is due to a TYPO.

See  variable pagemax, and noticed I goofed when I typed it into the sub, as pagmax... missing the e. That's when I noticed the crash the first time, and tracked it down to the missing value of the variable causing a division by zero problem with the MOD statement. Why it crashed instead of reporting it must have something to do with how that second loop compiles.

Note, this came from 500 lines of code, so it's missing a lot of variable assignments, so don't expect this to ever work as is, but if anyone would like to try and figure out why QB64 crashes with this code, assuming it will crash when you press a key to test it, a few lines to debug beats 500, any day.

Oh, if you remove these four line, it won't crash...

            SELECT CASE a$(j)
            CASE "<!--ID-->"
            a$(j) = "1"
            END SELECT

Pete

Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2.  
  3. pagemax = 10
  4. ovr = 3
  5. REDIM alpha(26), alpha$(26)
  6. REDIM SHARED a2$(10)
  7. a2$(1) = "test": noe = 1
  8.  
  9. CALL pete(t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())
  10.  
  11. SUB pete (t1$, t2$, noe, replace$(), pagmax, ovr, alpha(), alpha$())
  12.     STATIC a$(), origa$(), tcnt
  13.  
  14.     FOR i = 1 TO noe
  15.         x$ = MID$(LCASE$(a2$(i)), 1, 1)
  16.         IF x$ <> oldx$ THEN
  17.             j = ASC(x$) - 96
  18.             IF alpha$(j) = "" THEN
  19.                 alpha(j) = i
  20.                 pagenum = i \ pagemax + 1
  21.                 IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  22.             END IF
  23.         END IF
  24.     NEXT
  25.     PRINT "Pete": END
  26.     EXIT SUB
  27.  
  28.     FOR j = 1 TO tcnt
  29.         IF LEFT$(LTRIM$(a$(j)), 4) = "<!--" THEN
  30.             SELECT CASE a$(j)
  31.                 CASE "<!--ID-->"
  32.                     a$(j) = "1"
  33.             END SELECT
  34.         END IF
  35.     NEXT j
  36.  
Title: Re: MOD crashed my program!!!
Post by: FellippeHeitor on February 04, 2020, 08:25:03 pm
Code: QB64: [Select]
  1. 'at the top, with v1.4:
  2.  
  3. 'before the MOD line:
  4. _ASSERT pagemax > 0
  5.  

And to avoid typos,

Code: QB64: [Select]
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 08:29:05 pm
Fell, I'm not looking for a way around MOD 0, if I hadn't made the typo, it would never have been a zero, it would have always been MOD 10. What I can't figure out is why having that second FOR/NEXT loop in the code causes it to crash, and removing the SELECT CASE part causes it to properly show the division by zero error. That seems like a bug, meaning a failure of QB64 to trap that error.

Pete

Title: Re: MOD crashed my program!!!
Post by: SMcNeill on February 04, 2020, 08:45:20 pm
Are you certain it’s not this line:

                pagenum = i \ pagemax + 1

Integer division by 0 would crash the IDE with CONST unless it was properly error trapped, so it seems like here might be the actual cause of the problem.
Title: Re: MOD crashed my program!!!
Post by: FellippeHeitor on February 04, 2020, 08:55:13 pm
I tested your sample above, with no changes. Got the Division by zero dialog both in Windows XP 32bit and in macOS (which is always 64bit). Steve has a point there, with the integer division (\). Could be that, but it actually should give the same dialog. It's one of those hard to reproduce cases indeed.
Title: Re: MOD crashed my program!!!
Post by: bplus on February 04, 2020, 10:48:41 pm
OK I fixed 2 things after program did hang a circle and then bug out with Pete's code, mildest crash I've ever seen!
Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2. DIM pagemax, ovr, a2$, noe, t1$, t2$, replace$(1)
  3. pagemax = 10
  4. ovr = 3
  5. REDIM alpha(26), alpha$(26)
  6. REDIM SHARED a2$(10)
  7. a2$(1) = "test": noe = 1
  8.  
  9. CALL pete(t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())
  10.  
  11. SUB pete (t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())   'fix typeo on pagemax
  12.     STATIC a$(20), origa$(), tcnt  '<<<<<<<<<<<<<<<<<<<<<<< fix array with a dim number between ()
  13.     DIM i, x$, oldx$, j, pagenum
  14.     FOR i = 1 TO noe
  15.         x$ = MID$(LCASE$(a2$(i)), 1, 1)
  16.         IF x$ <> oldx$ THEN
  17.             j = ASC(x$) - 96
  18.             IF alpha$(j) = "" THEN
  19.                 alpha(j) = i
  20.                 pagenum = i \ pagemax + 1
  21.                 IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  22.             END IF
  23.         END IF
  24.     NEXT
  25.     PRINT "Pete": END
  26.     EXIT SUB
  27.  
  28.     FOR j = 1 TO tcnt
  29.         IF LEFT$(LTRIM$(a$(j)), 4) = "<!--" THEN
  30.             SELECT CASE a$(j)
  31.                 CASE "<!--ID-->"
  32.                     a$(j) = "1"
  33.             END SELECT
  34.         END IF
  35.     NEXT j
  36.  
  37.  
  38.  

and it works!

Why didn't STATIC a$() not signal an error? (see 2nd screen shot)
Update: OK that's the way STATIC works, so why didn't my fix through another error? the () are supposed to be empty according to Wiki.
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 11:05:34 pm
Hi Steve,

That's another division by zero, when the pagemax variable didn't get passed as 10 because of the typo in the sub call. The thing is, you can take that line out, which I agree would be the first division by zero encounter, and leave the MOD line in; it will still crash. So, that's a bit of a red herring. The crash is only eliminated when the SELECT CASE is removed, and that's weird, because that part of the program flow isn't even reached yet. Try this. Remove those 4 lines and it won't crash, it will just properly trap the division by zero error.

Hi Fell,

I tried it in version 1.2 just now, and got the same crash results. Like I mentioned, If I take the integer division out, and leave the MOD, it still crashes. Now here's an interesting one. I took both MOD and the integer division out, and substituted in PRINT 0 / 0. It actually completed, and printed: NAN      D

Now if I substitute in PRINT 0 \ 0 (integer division) it crashes again, with reporting a division by zero error. It's just really odd that it's the presence of the not yet engaged...

            SELECT CASE a$(j)
                CASE "<!--ID-->"
                    a$(j) = "1"
            END SELECT

... is what makes it crash. When I take those four lines out, it prevents the crash, and simply reports the division by zero error.


Hi Mark,

Yes, I knew about the variable typo. I fixed it before I made this thread, but I made the thread to point out the crash the division by zero caused. As you can see, Fell's system didn't crash, so this is a hard one to pin down. Also, yes, I know the other variables are empty, not defined, etc., but that's because I whittled this down from a 500 line sub. I left them as is, because they are not involved in the crash. What makes it crash is when the division by zero is encountered, and get this... only in the presence of that SELECT CASE code, which doesn't even come about in the program flow, until after the division by zero is encountered. So my concern is why does having those four lines crash it, and when those 4 lines are removed, it throws the appropriate division by zero error?
------------------------------------------------
I guess we chalk this one up as some rare oddity that hopefully won't ever affect a program without a coding error causing it.

Anyway, thanks for having a look guys,

Pete

Title: Re: MOD crashed my program!!!
Post by: bplus on February 04, 2020, 11:08:01 pm
OK this is probably how to fix the a$() thing:
Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2. DIM pagemax, ovr, a2$, noe, t1$, t2$, replace$(1)
  3. pagemax = 10
  4. ovr = 3
  5. REDIM alpha(26), alpha$(26)
  6. REDIM SHARED a2$(10)
  7. a2$(1) = "test": noe = 1
  8.  
  9. CALL pete(t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())
  10.  
  11. SUB pete (t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())
  12.     STATIC a$(), origa$(), tcnt
  13.     DIM i, x$, oldx$, j, pagenum
  14.     FOR i = 1 TO noe
  15.         x$ = MID$(LCASE$(a2$(i)), 1, 1)
  16.         IF x$ <> oldx$ THEN
  17.             j = ASC(x$) - 96
  18.             IF alpha$(j) = "" THEN
  19.                 alpha(j) = i
  20.                 pagenum = i \ pagemax + 1
  21.                 IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  22.             END IF
  23.         END IF
  24.     NEXT
  25.     PRINT "Pete": END
  26.     EXIT SUB
  27.  
  28.     DIM a$(20) '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< OK this is probably how it was supposed to be fixed
  29.     FOR j = 1 TO tcnt
  30.         IF LEFT$(LTRIM$(a$(j)), 4) = "<!--" THEN
  31.             SELECT CASE a$(j)
  32.                 CASE "<!--ID-->"
  33.                     a$(j) = "1"
  34.             END SELECT
  35.         END IF
  36.     NEXT j
  37.  
  38.  
  39.  
Title: Re: MOD crashed my program!!!
Post by: bplus on February 04, 2020, 11:11:06 pm
Hi Steve,

That's another division by zero, when the pagemax variable didn't get passed as 10 because of the typo in the sub call. The thing is, you can take that line out, which I agree would be the first division by zero encounter, and leave the MOD line in; it will still crash. So, that's a bit of a red herring. The crash is only eliminated when the SELECT CASE is removed, and that's weird, because that part of the program flow isn't even reached yet. Try this. Remove those 4 lines and it won't crash, it will just properly trap the division by zero error.

Hi Fell,

I tried it in version 1.2 just now, and got the same crash results. Like I mentioned, If I take the integer division out, and leave the MOD, it still crashes. Now here's an interesting one. I took both MOD and the integer division out, and substituted in PRINT 0 / 0. It actually completed, and printed: NAN      D

Now if I substitute in PRINT 0 \ 0 (integer division) it crashes again, with reporting a division by zero error. It's just really odd that it's the presence of the not yet engaged...

            SELECT CASE a$(j)
                CASE "<!--ID-->"
                    a$(j) = "1"
            END SELECT

... is what makes it crash. When I take those four lines out, it prevents the crash, and simply reports the division by zero error.

I guess we chalk this one up as some rare oddity that hopefully won't ever affect a program without a coding error causing it.

Thanks for having a look guys,

Pete

Pete

the a$() still needed to be DIM so no error occured until tried to use the a$().

You have same problem lurking with origa$() if you decide to use that.

Hey is a$ array supposed to be a2$() that is shared at top of code?
Title: Re: MOD crashed my program!!!
Post by: Pete on February 04, 2020, 11:18:01 pm
Hi Mark, please read my above edited reply. I posted back to Steve and Fell the same time you posted. As you will see, those other variables are just orphaned from what used to be 500 lines of code in a sub. I whittled the problem down so it could be tested. In other words, I could define and populate all of those arrays, and it wouldn't make any difference in the crash occurrence. The crash problem is independent of those variables. This was just the smallest amount of code I could whittle down to and still preserve the crash.

Pete
Title: Re: MOD crashed my program!!!
Post by: bplus on February 04, 2020, 11:26:59 pm
Hi Mark, please read my above edited reply. I posted back to Steve and Fell the same time you posted. As you will see, those other variables are just orphaned from what used to be 500 lines of code in a sub. I whittled the problem down so it could be tested. In other words, I could define and populate all of those arrays, and it wouldn't make any difference in the crash occurrence. The crash problem is independent of those variables. This was just the smallest amount of code I could whittle down to and still preserve the crash.

Pete

OK it doesn't crash with a$() not dim. It was OPTION _EXPLICIT that wouldn't let it go until DIM'd, with that commented out, it works with just typo fix.
Title: Re: MOD crashed my program!!!
Post by: SMcNeill on February 05, 2020, 12:13:26 am
OK it doesn't crash with a$() not dim. It was OPTION _EXPLICIT that wouldn't let it go until DIM'd, with that commented out, it works with just typo fix.

OPTION _EXPLICIT doesn’t accept STATIC as a valid way to declare variables, but it’s not part of the problem here.

The integer division by zero is generating the glitch, but the SELECT CASE is doing something which is completely bugging out the error handling.  In Linux, it’d probably toss an error for SEG FAULT, but for whatever reason, Windows tends to just crash without any warning when those pop up.

I’m thinking the STATIC a$() is a huge part of the problem as STATIC is half-implemented at best; buggy as hell at worst.

It’s really a case of multiple issues interacting and glitching together.  I’ll dig into it some more later this weekend, to see if I can give you more details on the issue, but I think it works like this:

STATIC isn’t properly working with A$() and initializing the memory.  This is the first ERROR, but it’s not one which the internal handlers catch and toss an exception for.

Division by 0 then tosses an error, but there’s already an unknown glitch on the stack.  We try and report this one.

By trying to report the second glitch, the first one bugs out as Windows just doesn’t want to tell us “Seg Fault, memory not initialized”, and the program crashes and dies.

I havent tried it yet, (I’m on my ipad ATM), but I wonder if you could replicate the glitch with something as simple as:

SUB foo
    STATIC a$()
     ERROR 5
    SELECT CASE a$(13)
     CASE whatever
    END SELECT
END IF

I’m thinking the code there is very likely to crash without any error for the reason I stated above.

I’ll dig further once I get more time, but my gut is telling me it’s a combination issue at work like this.
Title: Re: MOD crashed my program!!!
Post by: bplus on February 05, 2020, 12:31:28 am
Code: QB64: [Select]
  1. foo
  2.  
  3. SUB foo
  4.     STATIC a$()
  5.     ERROR 5
  6.     SELECT CASE a$(13)
  7.         CASE whatever$
  8.     END SELECT
  9.     PRINT "foo"
  10.  
  11.  

No crash, error 5 flagged illegal function call, continue? yes
a$(13) subscript out of range, continue? yes
Out put: foo

Title: Re: MOD crashed my program!!!
Post by: Pete on February 05, 2020, 05:34:20 am
Wow guys, this is a bug issue that really does need to be addressed. I broke the code down further. It simply won't error trap the division by zero in the presence of a SELECT CASE.

Note: I just didn't define the pagemax variable, so it's zero.

Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2.  
  3. IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  4.  
  5. SELECT CASE a$(j)
  6.  

If you take out the SELECT CASE, it error traps properly. If you run it as is, above, it will crash.

Pete
Title: Re: MOD crashed my program!!!
Post by: FellippeHeitor on February 05, 2020, 05:52:04 am
Thanks for the thorough report and for carrying on with pursuing a minimal reproducible example, Pete. We're certain to investigate and hopefully find a fix before v1.4 comes out (no promises though, especially as it doesn't look trivial).
Title: Re: MOD crashed my program!!!
Post by: FellippeHeitor on February 05, 2020, 08:24:29 am
Update: It crashed on me without an error box on Windows 10 64bit too.
Title: Re: MOD crashed my program!!!
Post by: bplus on February 05, 2020, 09:06:48 am
Right code crashes for me but this SELECT CASE does flag division by 0
Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2.  
  3. IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  4.  
  5.  

and this
Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2.  
  3. IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  4.  

and this
Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2. DIM a(20)
  3. k = 1: a(k) = 42
  4.  
  5. IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  6.  
  7.  
  8.  
  9.  

But not this, crashes:
Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2. DIM a$(20)
  3. k = 1: a$(k) = "Nutz"
  4.  
  5. IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  6.  
  7. SELECT CASE a$(k)
  8.  
  9.  

But this is OK?, well no crash back to division by 0
Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2. DIM a$(20)
  3. k = 1: a$(k) = "Nutz"
  4. b$ = a$(k)
  5. IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  6.  
  7.  
  8.  
  9.  
  10.  

Again back to division by 0 with SELECT CASE
Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2.  
  3. IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  4.  
  5.  
  6.  
  7.  
  8.  

b() is not dim just like a$() but here division by 0 is flagged.
Title: Re: MOD crashed my program!!!
Post by: Cobalt on February 05, 2020, 11:07:26 am
Mine system is still giving me a Division by Zero error at run time, same as always, with all

examples in various versions of QB64.


Not sure if your wanting it in the IDE before compile, based on my lite  perusing of  the posts,

but I guess its an OS issue not giving you the appropriate error box at run time.

Again, feel as if this is a programmer responsibly to know what range of values their variables

are capable of returning, not the IDEs.
Title: Re: MOD crashed my program!!!
Post by: Pete on February 05, 2020, 11:16:35 am
Hi Mark,

That's interesting. I tried some of those, and the only one I got to actually crash was when using a string array. It doesn't matter if it is or is not dimensioned, either.

PRINT "Press any key to test..."
SLEEP

IF i MOD pagemax = 0 THEN pagenum = pagenum - 1

SELECT CASE a$(1)
END SELECT

or...

PRINT "Press any key to test..."
SLEEP

IF i MOD pagemax = 0 THEN pagenum = pagenum - 1

DIM a$(1)
SELECT CASE a$(1)
END SELECT

----------------------------------------

Both examples using a string variable a$(1), in one example NO DIM and DIM in the other, crash. Just like your experiments, if I change a$(1) to just a$ or a, it properly reports division by zero, which occurs in the MOD statement for anyone just picking up on this thread.

Now it WON'T crash if you change SELECT CASE a$(1) to SELECT CASE VAL(a$(1))

So once we convert a string to a numeric value, QB64 is once again able to trap and display a division by zero error.

Also, this only seems to be happening when used in SELECT CASE. You can get rid of the SELECT CASE statement, and just put a PRINT a$(1) or put in a DO UNTIL a$(1) = "" : LOOP ... and it WON'T crash, either. So far, the only crash is with SELECT CASE.

@ COBALT: What OS are you running? One test Fell used was on a Windows XP 32-bit, and it didn't crash, but his 64-bit Win 10, which is what I'm using and I think what Mark is testing on, crashed. BTW - This isn't an IDE issue. It is only a compiled code issue. I agree with you the IDE should not be responsible for checking division by zero, especially when a variable is used as the divisor. Thanks for testing!

Pete
Title: Re: MOD crashed my program!!!
Post by: Cobalt on February 05, 2020, 11:26:44 am
Windows  Vista(64bit) and 7(64bit).  QB64x32 Versions 1.1release, 1.1\82 (with my own adds), 1.2, 1.3, 1.3dev, and 1.4 RC.

they all give Divide by Zero error box at run time.

Probably something else Microdorks messed up in Win 10.

Title: Re: MOD crashed my program!!!
Post by: bplus on February 05, 2020, 11:27:14 am
Hi Pete,

I just realized the DIM of arrays doesn't matter because QB64 gives you the first 10 free without DIM plus using j index when no value has been assigned is same as index 0.

so a$(j) evaluates to ""?

Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2.  
  3. IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  4.  
  5.  
  6.  
  7.  

BINGO! (It crashes from IDE on my win 10-64 Intel core i5 laptop running QB64 v1.3 standard issue)
Title: Re: MOD crashed my program!!!
Post by: bplus on February 05, 2020, 11:39:13 am
OK guys check this one out!
Code: QB64: [Select]
  1. PRINT "Press any key to test..."
  2.  
  3. IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
  4.  
  5.     CASE "b": PRINT "foo"
  6.  

You'll never guess what happens here!

Update: well I thought we'd be back to division by 0 but no, get crashes with string literals, no crashes with string variables, numbers or number variables.