PC-BASIC reported bug: ZeroDivisionError: float division by zero

[Kenneth Wayne Boyd]

Environment: Windows 7 Professional Servie Pack 1, 64 bit, Lenovo X200 16GB memory
Started from: Administrator: c:\Windows\System32\cmd.exe [command window]
Start command: C:\Users\Ken\c:\progra~2\pc-basic\pcbasic.exe --preset=pcjr
Activity:
Program (referenced below) loaded from website cited in REM
http://www.atarimagazines.com/compute/issue56/143_1_IBM_Personal_Computing.php

Several typo's had to be fixed for the program to run.
The session was not restarted and I issued many 'Load"MUSDISP" commands after editing with Sublime Text 3.
It finally worked, and I was playing through the song list. Songs 1-4 all worked..
While playing song 5, "Fast", "Mary Had a Little Lamb" the EXCEPTION screen appeared.

I created the beginning of this bug report and closed PC-BASIC by typing "system" and restarted from a CMD window with administrator priviledge as described above.

I attempted to recreate the problem:
Entered the following commands:
load"MUSDISP"
run
[entered:] 5
[entered:] f
EXCEPTION screen appeared in the music at about "Mary had a little lamb, little lamb [EXCEPTION"
The music continued to play, however, until completion with the EXCEPTION screen showing.

I tried input as [5][s] but there appears to still be a program bug as it resulted in
"Missing operand in 410"

The bug recreates solid with input of "5" and "f"

Hopefully, the problem recreates for you.

If there is any more information you need, let me know.

Ken

p.s. The previously reported "program crash" exceptions have appeared once... but I was using the standard GUI start PC-BASIC from the start menu. I have not been able to reproduce it at will yet. I have not seen a crash when starting with "Run as administrator"

=======================
EXCEPTION
490 PLAY "T 120O3MFMNL4" + MID$(B$, INSTR(B$," = ") + 3)
pcbasic.run:66, run_once
None
pcbasic.statements:198, parse_statement
None
pcbasic.statements:577, exec_play
None
pcbasic.sound:299, play
None
ZeroDivisionError: float division by zero
This is a bug in PC-BASIC.
Sorry about that. Please send the above messages to the bugs forum
by e-mail to bugs@discussion.pcbasic.p.re.sf.net or by filing a bug
report at https://github.com/robhagemans/pcbasic/issues. Please include
as much information as you can about what you were doing and how this happened.
Thank you!
Ok

======================= MUSDISP.BAS ===========================
5 REM from: http://www.atarimagazines.com/compute/issue56/143_1_IBM_Personal_Computing.php
6 REM several typo's fixed
7 REM 5/30/2016 kwb
10 X$ (1) = "America = GGAF + 4 .G8ABBo4Co3 B4 .A8GAGF + G2.O4DDDD4.C8o3Bo4CCCC4.o3B8ABo4mlC8o3B8A8mnG8B4.O4C8DmlE8mnC8o3BAG2."
20 X$ (2) = "America the Beautiful = GG4.E8EGG4.D8DEFGABG2.GG4.E8EGG4.D8 Do4DC + DEo3Ao4D2.o3Go4E4.E8DCC4.o3B8Bo4CDo3BAGo4C2."
30 X$ (3) = "Silent Night = T65mIF8.mnG16F8D4.mlF8.mnG16F8D4.o4CC8o3A4.B-B-8F4.GG8mlB-8.mnA16G8mlF8.mnG1 6F8D4."
40 X$ (4) = "William Tell Overture = L 16o3DDDp 16DDDp 16DDG8AB8DDDp 16DDDp 16BBA8G-8D8DDp 16DDDp 16DDG8A8B8p 16Go4D4p8o3G8B8G8"
50 X$ (5) = "Mary Had a Little Lamb = t 100o3L8GFE-FGGGp8FFF4GB-B-4GFE-FGGGGFFGFe-0."
60 X$ (6) = "="
70 X$ (7) = "="
80 X$ (8) = "="
90 X$ (9) = "End Program ="
100 KEY OFF
110 CLS : PRINT "Tunes"
120 FOR I = 1 TO 9
130 PRINT I ;Mid$ (X$ (I), 1, INSTR (X$ (I), "=") -1)
140 NEXT
150 PRINT : PRINT "Enter tune number :";
160 A$ = INKEY$ : IF A$ = "" THEN 160
170 I = VAL (A$)
180 IF I = 0 THEN GOTO 110
190 IF I = 9 THEN END
200 B$ = X$ (I)
210 PRINT
220 REM
230 PRINT "Enter : F for fast or S for slow :";
240 A$ = INKEY$ : IF A$ = "" THEN 240
250 IF A$ = "F" OR A$ = "f" THEN GOTO 460
260 PRINT
270 '-- Begin Slow Mode --
280 TIT$ = MID$ (B$, 1, INSTR (B$, "=")-1) : PRINT TIT$
290 PLAY "T 120O3MFMNL4"
300 C$ = MID$ (B$, INSTR (B$,"=") + 1) + " "
310 C$ = MID$ (C$, 1, INSTR (C$," ")-1)
320 KK = LEN (C$) : KIK = 0 : T$=""
330 FOR KI = 1 TO KK
340 IF KI MOD 25 = 0 THEN PRINT
350 W$ = MID$ (C$, K1, 1)
360 IF W$ < "A" OR W$ > "G" THEN GOTO 390
370 COLOR 15 : PRINT T$;" "; : PLAY T$ : COLOR 7 : LOCATE, POST(0)-(LEN(T$) + 1) : PRINT T$;" ";
380 T$ = ""
390 T$ = T$ + W$
400 NEXT KI
410 COLOR 15 : PRINT T$;" " : PLAY T$ : COLOR 7 : LOCATE, POS(0)-(LEN(T$) + 1) : PRINT T$ : " ";
420 PRINT : PRINT
430 PRINT : PRINT "Press any key to continue.";
440 A$ = INKEY$ : IF A$ = "" THEN 440
450 GOTO 110
460 '--End Slow Mode -- Begin Fast Mode --
470 PRINT : PRINT : PRINT
480 TIT$ = MID$(B$, 1, INSTR(B$, "=")-1) : PRINT TIT$
490 PLAY "T 120O3MFMNL4" + MID$(B$, INSTR(B$," = ") + 3)
500 GOTO 110

[Rob Hagemans]

Hi Ken, thanks for the report and all the extra info!

It looks like PC-BASIC can’t handle the “e-0” note at the end of the score for “Mary had a little lamb”. I’ll fix that – not sure yet what it is supposed to do but dividing by zero certainly isn’t the correct thing.

Thanks again for trying to debug the program crashes with audio – it’s interesting that it doesn’t seem to happen as Administrator. That certainly suggests a permissioning issue, though the unpredictability is strange. Do you get the issue when running from a non-Administrator command prompt?

Of course, running as Administrator is in general not recommended when not debugging – you’re basically giving the BASIC program full access to your system which is a security risk.

Thanks
Rob

[Anonymous]

I'm glad it was an easy to find.

The source for that program looked like it was perhaps an OCR input from a magazine article. There were vaious other changes I had to make to get the BASIC program to run. I thought the "0." might have been an undocumented "N0." or "Pause." However, trying it on a virtual Windows XP system running GWBASIC seemed to indicate that GWBASIC treated it as a "no-op."

It could be a missing note, I'll have to look at some examples of "Mary Had a Little Lamb" sometime... my ear isn't trained enough to notice an obvious music problem.

So, I figure it was probably corruption from the OCR process.

Thanks for the update.
Ken

[Rob Hagemans]

Hi Ken, the original program in Compute Magazine seems to have a number of typos (they're also in the PDF, so I think it's human error rather than OCR). The 0 may indeed be another one of them. The 'correct' behaviour seems to be for E-0 to be played the same as E-, which I have now implemented in PC-BASIC for the next release.

[Anonymous]

I agree, and thanks for the update.