LOAD memory leak

MZ952Created: ~7 years ago

It might just be a reformatting procedure, but—

COMMON DEF T S$
VAR A$
LOAD S$,0OUT A$
STOP
END

Edit: added COMMON and removed space before OUT After you call T with a valid file extension and name within S$ (ex. "TXT:FILE") print the variable S$ on the console. The contents of the string have been modified as a result of the load instruction. If you print S$ during runtime, the anomaly does not occur. I'm not sure what the modified string characters are for, I can only guess that it's SB's way of converting the name and extension into something the file system can use.

~7 years agoEdited ~7 years ago by MZ952

12Me21 #2

I can't get it to happen. Are you sure this is the exact code you're using?

~7 years ago

MZ952 #3

I can't get it to happen. Are you sure this is the exact code you're using?

I have restarted my system and tested the code again. I will rewrite the code exactly as I have it, though it really doesn't differ. Edit: I'm using the N3DS, and version 3.3.2

~7 years agoEdited ~7 years ago by MZ952

niconii #4

I can reproduce it on US 3.5.2. Upon some testing, this has nothing to do with LOAD. The following program does the same thing:

COMMON DEF T S$
 STOP
END

Steps to reproduce: 1. Type the above program into Slot 0. 2. Go back to Direct mode and press Start to run it. 3. Type T"Some string" in Direct mode and press A. 4. Type ?S$ in Direct mode and press A. Interestingly enough, though only the first five characters were corrupted for me, upon writing a FOR loop that would iterate over each character and print it in hex, the entire string became corrupted. My theory is that S$ ends up actually pointing to freed memory. Something else notable is that CLEAR failed to clear S$, though writing a new program and running that did clear it.

~7 years agoEdited ~7 years ago by niconii

DrZog #5

Step 3 just gives me a syntax error, are you sure that's correct?

T"Some string"
Syntax Error

~7 years ago

niconii #6

You skipped step 2. You have to press Start to load the program, otherwise T won't be recognized.

~7 years ago

DrZog #7

You skipped step 2. You have to press Start to load the program, otherwise T won't be recognized.

Your example program is missing the T. That's the problem. I followed your steps exactly.

~7 years agoEdited ~7 years ago by DrZog

12Me21 #8

oh it's COMMON DEF I didn't see that before.

~7 years ago

niconii #9

Ah, crap, you're right. Typo.

~7 years ago

MZ952 #10

Wow, this is interesting. I didn't bother to take the load instruction out and test it, I just figured it was related. So, it would appear to me that the STOP instruction is what's causing this. Guess I should rename this so. Edit: can't rename the heading. Lol oh well, I'm curious to see what other quirks this presents.

~7 years agoEdited ~7 years ago by MZ952

12Me21 #11

A few strange things: 1: function must be COMMON 2: program must be stopped from inside the function 3: function must be called from direct mode 4: a string literal (not a variable) must be passed to the function

~7 years ago

MZ952 #12

A few strange things: 1: function must be COMMON 2: program must be stopped from inside the function 3: function must be called from direct mode 4: a string literal (not a variable) must be passed to the function

Those are some very specific demands for this bug. Interestingly, if you tell the function to print S$ after the STOP instruction, and CONT the execution after calling T, the string will be printed unwaveringly, but if you chose to print the variable from DIRECT mode after STOPping, continuing the execution will print the faulted string.

~7 years ago