Hi, I’m trying for days on a bug that doesn’t allow me to use the program properly. I know that the code has pile up quite large instead of modulating it using CHAIN statements. But it was only a file reader in characters and bytes for those days when I didn’t have hex editor (except for debug on DOS, which I wasn’t good for it).
The thing is that I have been dismantling the program to isolate the problem. I need help if it’s a matter of improper logic behavior code, or there is a bug that needs quite an attention. I always compare the run of the program with GWBASIC (using DOSBOX), which it runs very well. But when I use it with PC-BASIC it seems, after 40 keystrokes, makes the platform to crash-end. I really wish to able the program in PC-BASIC because it’s faster, simpler and the window is very comfortable.
Maybe there’s a way to detect the failure in a more equipped IDE tool to diagnostic the issue. I could send you the code, but it’s a little large, perhaps 300 lines. Is there’s any way that you can analyze or debug it at your end to see what’s the problem. Tell me what you think.
Ronald.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ronald,
If there is a crash, that means it is a bug in PC-BASIC. Best would be if you could send me the code so I can see what is going on - 300 lines is not a problem. It may be easiest to add the file as an attachment to a forum post (using the link below the message editor) rather than pasting the code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a particular file or something you usually do just before it crashes? When I use the program to read through a text file with arrow keys I don't get a crash.
Does the crash also happen if you disable to SOUND commands in the code or run with nosound=True? I recall that there was an unsolved issue with repeated sounds making PC-BASIC crash on some 64-bit Windows installs - is this crash similar?
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, When you say garbage collection code, are you referring to the control characters (substituted by a inverted colored “*” (asterik)? The bug happens when you move the number of record blocks with keystroke using up and/or down (or PageUp or PageDown) about 40 times. It happens to when you try to FIND (F5) a keyword. Ronald.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, that wasn't very clear - I mean the code inside PC-BASIC (and GW-BASIC) that gets triggered whenever the string space in memory gets filled up. It moves all the strings consecttively to the top of string space, much like defragmenting a hard drive. This happens automatically when memory gets tight (in CHKBYTE4 this is on page 45 of a file) but also when you call FRE with a string argument. For example, the same crash you reported happens immediately if you do OPEN "TEST" FOR RANDOM AS 1: FIELD#1, 128 AS A$: PRINT FRE("").
It is fixed now in the development code, so will be OK in the next minor release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "[CLOSED] General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi, I’m trying for days on a bug that doesn’t allow me to use the program properly. I know that the code has pile up quite large instead of modulating it using CHAIN statements. But it was only a file reader in characters and bytes for those days when I didn’t have hex editor (except for debug on DOS, which I wasn’t good for it).
The thing is that I have been dismantling the program to isolate the problem. I need help if it’s a matter of improper logic behavior code, or there is a bug that needs quite an attention. I always compare the run of the program with GWBASIC (using DOSBOX), which it runs very well. But when I use it with PC-BASIC it seems, after 40 keystrokes, makes the platform to crash-end. I really wish to able the program in PC-BASIC because it’s faster, simpler and the window is very comfortable.
Maybe there’s a way to detect the failure in a more equipped IDE tool to diagnostic the issue. I could send you the code, but it’s a little large, perhaps 300 lines. Is there’s any way that you can analyze or debug it at your end to see what’s the problem. Tell me what you think.
Ronald.
Hi Ronald,
If there is a crash, that means it is a bug in PC-BASIC. Best would be if you could send me the code so I can see what is going on - 300 lines is not a problem. It may be easiest to add the file as an attachment to a forum post (using the link below the message editor) rather than pasting the code.
Okay, Thanks.
Check Attachment. Ron.
Last edit: Ronald Herrera 2015-12-10
Thanks!
Is there a particular file or something you usually do just before it crashes? When I use the program to read through a text file with arrow keys I don't get a crash.
Does the crash also happen if you disable to
SOUNDcommands in the code or run withnosound=True? I recall that there was an unsolved issue with repeated sounds making PC-BASIC crash on some 64-bit Windows installs - is this crash similar?Rob
Don't worry about this, I've found the issue - it's a problem in the garbage-collection code that is called when the array memory fills up.
Hi, When you say garbage collection code, are you referring to the control characters (substituted by a inverted colored “*” (asterik)? The bug happens when you move the number of record blocks with keystroke using up and/or down (or PageUp or PageDown) about 40 times. It happens to when you try to FIND (F5) a keyword. Ronald.
Sorry, that wasn't very clear - I mean the code inside PC-BASIC (and GW-BASIC) that gets triggered whenever the string space in memory gets filled up. It moves all the strings consecttively to the top of string space, much like defragmenting a hard drive. This happens automatically when memory gets tight (in
CHKBYTE4this is on page 45 of a file) but also when you callFREwith a string argument. For example, the same crash you reported happens immediately if you doOPEN "TEST" FOR RANDOM AS 1: FIELD#1, 128 AS A$: PRINT FRE("").It is fixed now in the development code, so will be OK in the next minor release.
View and moderate all "[CLOSED] General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Okay! :-) /Ron.