MOD crashed my program!!!

[FellippeHeitor]

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?

[Pete]

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

[Pete]

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. SLEEP
3.  
4. pagemax = 10
5. ovr = 3
6. REDIM alpha(26), alpha$(26)
7. REDIM SHARED a2$(10)
8. a2$(1) = "test": noe = 1
9.  
10. CALL pete(t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())
11.  
12. SUB pete (t1$, t2$, noe, replace$(), pagmax, ovr, alpha(), alpha$())
13.     STATIC a$(), origa$(), tcnt
14.  
15.     FOR i = 1 TO noe
16.         x$ = MID$(LCASE$(a2$(i)), 1, 1)
17.         IF x$ <> oldx$ THEN
18.             j = ASC(x$) - 96
19.             IF alpha$(j) = "" THEN
20.                 alpha(j) = i
21.                 pagenum = i \ pagemax + 1
22.                 IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
23.             END IF
24.         END IF
25.     NEXT
26.     PRINT "Pete": END
27.     EXIT SUB
28.  
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. END SUB
38.  

[FellippeHeitor]

Code: QB64: [Select]

1. 'at the top, with v1.4:
2. $ASSERTS
3.  
4. 'before the MOD line:
5. _ASSERT pagemax > 0
6.  

And to avoid typos,

Code: QB64: [Select]

1. OPTION _EXPLICIT

[Pete]

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

[SMcNeill]

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.

[FellippeHeitor]

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.

[bplus]

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. OPTION _EXPLICIT
2. PRINT "Press any key to test..."
3. SLEEP
4. DIM pagemax, ovr, a2$, noe, t1$, t2$, replace$(1)
5. pagemax = 10
6. ovr = 3
7. REDIM alpha(26), alpha$(26)
8. REDIM SHARED a2$(10)
9. a2$(1) = "test": noe = 1
10.  
11. CALL pete(t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())
12.  
13. SUB pete (t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())   'fix typeo on pagemax
14.     STATIC a$(20), origa$(), tcnt  '<<<<<<<<<<<<<<<<<<<<<<< fix array with a dim number between ()
15.     DIM i, x$, oldx$, j, pagenum
16.     FOR i = 1 TO noe
17.         x$ = MID$(LCASE$(a2$(i)), 1, 1)
18.         IF x$ <> oldx$ THEN
19.             j = ASC(x$) - 96
20.             IF alpha$(j) = "" THEN
21.                 alpha(j) = i
22.                 pagenum = i \ pagemax + 1
23.                 IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
24.             END IF
25.         END IF
26.     NEXT
27.     PRINT "Pete": END
28.     EXIT SUB
29.  
30.     FOR j = 1 TO tcnt
31.         IF LEFT$(LTRIM$(a$(j)), 4) = "<!--" THEN
32.             SELECT CASE a$(j)
33.                 CASE "<!--ID-->"
34.                     a$(j) = "1"
35.             END SELECT
36.         END IF
37.     NEXT j
38. END SUB
39.  
40.  
41.  

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.

[Pete]

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

[bplus]

OK this is probably how to fix the a$() thing:

Code: QB64: [Select]

1. OPTION _EXPLICIT
2. PRINT "Press any key to test..."
3. SLEEP
4. DIM pagemax, ovr, a2$, noe, t1$, t2$, replace$(1)
5. pagemax = 10
6. ovr = 3
7. REDIM alpha(26), alpha$(26)
8. REDIM SHARED a2$(10)
9. a2$(1) = "test": noe = 1
10.  
11. CALL pete(t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())
12.  
13. SUB pete (t1$, t2$, noe, replace$(), pagemax, ovr, alpha(), alpha$())
14.     STATIC a$(), origa$(), tcnt
15.     DIM i, x$, oldx$, j, pagenum
16.     FOR i = 1 TO noe
17.         x$ = MID$(LCASE$(a2$(i)), 1, 1)
18.         IF x$ <> oldx$ THEN
19.             j = ASC(x$) - 96
20.             IF alpha$(j) = "" THEN
21.                 alpha(j) = i
22.                 pagenum = i \ pagemax + 1
23.                 IF i MOD pagemax = 0 THEN pagenum = pagenum - 1
24.             END IF
25.         END IF
26.     NEXT
27.     PRINT "Pete": END
28.     EXIT SUB
29.  
30.     DIM a$(20) '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< OK this is probably how it was supposed to be fixed
31.     FOR j = 1 TO tcnt
32.         IF LEFT$(LTRIM$(a$(j)), 4) = "<!--" THEN
33.             SELECT CASE a$(j)
34.                 CASE "<!--ID-->"
35.                     a$(j) = "1"
36.             END SELECT
37.         END IF
38.     NEXT j
39. END SUB
40.  
41.  
42.  

[bplus]

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?

[Pete]

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

[bplus]

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.

[SMcNeill]

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.

[bplus]

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. END SUB
11.  
12.  

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