Differences

This shows you the differences between two versions of the page.

--- bughunt:bugs [2020/11/05 11:09] – frantic
+++ bughunt:bugs [2021/04/26 19:55] (current) – removed frantic
@@ Line 1: / Line 1: @@
-====== Bug hunting ======
-On the whole defMON is a fairly stable program, but there are some glitches here and there. If you find reproducible bugs yourself, don't hesitate to let me know. The preferred way to report a bug is to add a description of the problem on this page.
-To get a username and a password, send a message to [[https://csdb.dk/scener/?id=8093|the author of defMON]] on CSDb  where you specify the username you want and your email.
-Please make sure that you are using the [[download:download|latest version]] of defMON before reporting a bug!
-===== BUG: Instrument deletion bug =====
-(Reported 2020-05-16 by F7sus4 at chipmusic.org)
-If you load previously made tune, then delete large chunks of instrument data with shift+RETURN, and proceed to save the file, it might become corrupted. This does not happen if instrument lines are erased byte-by-byte with space bar.
-It's difficult to predict whether this behavior is related to memory allocation or instrument jump points that defMON tries to recalculate while erasing consecutive lines.
-defMON asks:
-A question of clarification here. What does "large chunks of instrument data" refer to here? Like.. just deleting a few rows, or... something like changing the block size and keeping SHIFT+RETURN pressed to delete like most of the instrument data? And also, what is it that gets corrupted? Is it the sidtab data specifically that gets corrupted (how? some random data shows up?), or does it seem to corrupt other data (like sequence data or whatever)?
-F7sus4 says:
-"Deleting large chunks of data" basically meant interaction, and especially deletion of large amount of subsequent lines in instrument/sound program data "tab" using shift+return shortcut. It is sometimes possible to trigger the state when the saved file becomes corrupted afterwards and thus, impossible to load again. I suspect that this sort of data leakage might be somehow related to the pattern/sequence data as well, as a result allowing to trigger the "pattern overwrite bug".
-defMON says:
-If you have a tune that is created in the latest version of defMON and that gets corrupted like this, so it can't be loaded again, I would be very interested in having a look at the corrupted file.
-F7sus4 says:
-The bug happened again just today, so I'm sending the affected file. Should be in your inbox shortly.
-===== BUG: Patterns getting overwritten (2SID only) =====
-(This was reported 2020-07-28 by F7sus4 at chipmusic.org)
-When working in 2SID mode, it is possible to have your existing sequences/patterns overwritten by copying using shift+U. It seems to affect sequences in SID2 list only, while copying sequences in SID1 list, but not vice versa.
-(Further updated 2020-08-02 by F7sus4)
-I've spent several hours trying to trigger the bug with clean start yesterday, but with no luck. This leads me to assumption that the circumstances involved are complicated. It always happened during multi-hour extensive music editing.
-Gut feeling/guess: I also remember reporting that deleting large chunks of instrument data might result in misbehaving sound and (sometimes) corrupted file after saving. This leads me to conjecture that there could be some sort of data leakage in this area which might also interfere with pattern data resulting in said behavior. If not, there are no other existing-and-pending data issues I could think of right now. Will keep looking.
-defMON says:
-I don't know if any of you ever run defMON in VICE, but if you do:
-One thing that might help the bug hunting is to load up the latest official version of defMON in VICE.
-Then pull up the monitor (usually found in the menus, depending on which version of VICE you use).
-Then cut/paste the following lines there:
-<file>
-break $e4dd if X > $7f
-break $e4ed if X > $7f
-</file>
-Then type "x" and press enter to leave the monitor. Now you can use defMON normally. However, IF the monitor window pops up again automatically at some point, that gives me at least a little clue about the problem. If this happens, you should also save your tune under a new name, because some data corruption may have ocurred.
-You can type "x" and press enter to leave the monitor again. If the monitor window keeps popping up, just type:
-<file>
-disable 1 <ENTER>
-disable 2 <ENTER>
-x <ENTER>
-</file>
-...and the monitor window will stop popping up.
-F7sus4 says:
-Mini-update: I was working on my next 2SID release recently, and I happened to trigger the bug once again (C64C, 250469 mobo@8580x2). This is not really an update or any sort of detailed feedback unfortunately, but rather a confirmation that it is there, however, it happens extremely rarely.
-There were no specific circumstances that would allow me to reproduce the bug at will once more.
-defMON says:
-Do you know if the tune was playing when you copied the sequence, or if the music playing was stopped?
-F7sus4 says:
-) The music was playing at the time (2 sequence-long loop: both on SID1 and SID2 side).
-) I've copied it to make 4 sequence loop instead, and I've worked on it, on the fly.
-) When I've eventually removed the loop command in the list, I then realized that one of the final patterns/sequences became overwritten in the process.
-This might be a coincidence, but out of few times this ever happened, it was always SID2 sequence that became overwritten.
-===== BUG: Custom multi-speed setting stability issue =====
-(This was reported 2020-08-05 by F7sus4 at chipmusic.org)
-defMON by default supports x1, x2, x4 and x8 multispeed mode, which in timer settings translates to $2663 for x2, $1331 for x4 etc.
-However, we are also free to achieve x3 multispeed with $1997 manual setting (same with e.g. x6 or x9).
-Now, if we choose x2 mode first and we slide the timer down to $1997, it will work stable in the new "custom" x3 mode. But if we choose x4 mode and slide the timer up to $1997, the pattern will play twice as slow as previously and the software will suffer from multi-second hangups in which there will be no response from the keyboard input. This state will pass after a minute or two, but it renders the program unusable during the time.
-defMON says:
-@F7sus4: Thanks again for all your hard work reporting bugs and quirks. Regarding the keyboard hangup; yes, that's definitely a bug/quirk in the sense that I haven't implemented any protection against that. It may be possible to do that, so I'll put that on the "possible things to fix in defMON" list. Regarding 4x playing the sequence half as fast as 2x, that is the way it should be. "2x" means "call sidtab parsing twice for every time sequences are parsed" and "4x" means "call sidtab parsing four times for every time sequences are parsed".
-F7sus4 says:
-@F7sus4: Thanks again for all your hard work reporting bugs and quirks. Regarding the keyboard hangup; yes, that's definitely a bug/quirk in the sense that I haven't implemented any protection against that. It may be possible to do that, so I'll put that on the "possible things to fix in defMON" list. Regarding 4x playing the sequence half as fast as 2x, that is the way it should be. "2x" means "call sidtab parsing twice for every time sequences are parsed" and "4x" means "call sidtab parsing four times for every time sequences are parsed".

User Tools

Site Tools

Differences

Page Tools