Re: FTS crash

Hi Joseph,

V. sorry about that...

A bit of a loss what to do. The message usually means a program tried to access an area
of memory that hasn't been allocated to it, and the rest of the information is only really useful
if you are working at a v. low level, e.g. assembly language rather than c.

I've just uploaded next version of the beta today.
http://members.nbci.com/tune_smithy/fts_beta/fts_beta_download.htm

I'd v. much like to try to fix it, but would need more information, haven't got much to go on
at present,

I can't duplicate it here.

Sounds as if it may be happening somewhere in the tune or the sound generation, and since it
happens for playing just the seed as well, that localises it quite a bit - prob. to the part
concerned with sending notes to MIDI out, or else perhaps to the part of the code to do
with working out the pitch to play from the scale and arpeggio definitions.

However that is still a large amount of code - getting on for 2000 lines. Also made a fair number
of changes there.

So what I'd need to do is to make a version the beta with debug code in it, which you could
activate by typing, say, #dbg into the time for one note box.

Then you'd download it, crash it, and send the log file it makes to me. It would just consist of lots of lines like
Reached line such and such
Reached line such and such, relevant variables such and such,
etc.

I could look at that and hopefully see which line it crashed in. May need to do it again, maybe
two or three times, esp. if it turns out to be happening in another part of the program instead
(e.g. in section called from that part).

This isn't completely guaranteed to work because occasionally in this situation,adding in debug code
can change it enough to stop it from crashing, but since the bug seems to be pretty easy to repeat,
I would expect it to quite likely work.

Making sure FTS doesn't crash is my top priority, so I hope you can help with this, - nobody else
has yet reported this bug to me.

Robert

--- In tuning@egroups.com, "Robert Walker" <robert_walker@r...> wrote:

http://www.egroups.com/message/tuning/15959

> Hi Joseph,
>
> V. sorry about that...
>
> A bit of a loss what to do. The message usually means a program
tried to access an area of memory that hasn't been allocated to it,
and the rest of the information is only really useful
> if you are working at a v. low level, e.g. assembly language rather
than c.
>
Oh yeah... I guess so... It's just a bunch of hexadecimal numbers or
something...

> I've just uploaded next version of the beta today.
> http://members.nbci.com/tune_smithy/fts_beta/fts_beta_download.htm
>

Well, I'll try this one, and see if it works any better...

> So what I'd need to do is to make a version the beta with debug
code in it, which you could activate by typing, say, #dbg into the
time for one note box.
>
> Then you'd download it, crash it, and send the log file it makes to
me. It would just consist of lots of lines like
> Reached line such and such
> Reached line such and such, relevant variables such and such,
> etc.
>

Well, this is no problem. Just tell me exactly what to do...

I'll try the newest beta first, just to see if it works any better...
by comparison, now the "older" one is a disappointment!

> This isn't completely guaranteed to work because occasionally in
this situation,adding in debug code can change it enough to stop it
from crashing

This is funny... well, ok, it's funny to ME, but it wouldn't be very
funny to anyone programming the thing...

>
> Making sure FTS doesn't crash is my top priority, so I hope you can
help with this, - nobody else has yet reported this bug to me.
>
Well, I can't imagine there's anything that "special" about my own
setup...

I'll try the most recent beta, hopefully this evening (NYC time)...
_____ ___ __ _ __
Joseph Pehrson

Hi Joseph...

>Well, I just downloaded the new beta Smithy right now. It's 9:40PM
>New York time, so it means it's 3:40AM your time... Gee, you work
>really late... or EARLY!

Late, fairly often, though v. irregular.

>Ummm. It crashes again. Same thing...both in playing scales and
>playing "seeds."

Ah well, anyway suggest it is a pretty robust bug, which is hopeful.

>So, I uninstalled the entire thing and went back to the older
>"authenticated" version of Smithy, since I cannot now be without a
>working version of Smithy!

Glad you find it so useful!

Actually, you can keep both installations - works fine, any number of
copies of the program are okay - just install each version in a new directory
- if you use the installer, you just need to change the Destination directory
and the Program folder for each version. (1.09 needs some new files in its
folder that 1.082 doesn't have)

>It seems like the earlier version of the beta worked for me just
>fine... I wonder what's happening

If you want to go back to 14th Oct release of beta, I've put link
to the .exe file on the download page.

That is the beta for immediately after I did the complete ascending
Mode / arpeggio for Follow scale and complete Scale up to octave.

You can save that one into same directory as the buggy beta if you
like, and use it in its place until I've got it sorted out.

But hopefully will get this sorted out pretty quickly!

>Well, perhaps a "crash-beta" is in order, with clear instructions as
>to post-demolition...

Okay.

Download:

http://www.robertwalker.f9.co.uk/FractalTuneSmithySetup_109_beta_debug.exe

(setup prog)

(Say if you prefer the zip / se zip.)

I've changed the default program folder and destination directory both to Fractal Tune Smithy Debug.

Once installed and it's running, tick the new box "Debug log" in the main window.

Everything will then be a bit slower because of the debug log.

Play a seed (I think of the that may be easier for debugging poss.)

When you press the button, it may not change to the yellow square immediately, because
of all the writing to file with the debug log, but just wait. If you click again at
that point, it will prob. stop playback before it gets to the bug.

Hopefully, it crashes at that point!

Then look in the directory - c:\Program Files\Fractal Tune Smithy
(or whatever you named it to) and look for the file
DEBUG_LOG, which will be the most recent one in the folder

Here, after playing complete seed, the file is 65-70 KB or so, (3500 lines or so
of output), so will prob. be less than that

If it goes into a runaway loop it could get v. large. Doesn't sound like
that sort of bug - it would either stop responding, or generate a
stack fault. But as a precaution I've set it to stop making the log file
if it reaches 10,000 lines of output (still small enough to send easily).

Whenever you tick the "Debug log" box, it remakes the log file anew, in case Smithy
doesn't crash, and you want to have another go (may be worth a second try
if it doesn't crash)

Send it to me, and I'll see what I can make of it.

Cheers,

Robert

--- In tuning@egroups.com, "Robert Walker" <robert_walker@r...> wrote:

http://www.egroups.com/message/tuning/16050

Hello Robert!

Well, you warned me that this might happen... Now that you included
the "debug" code, the program works perfectly....

It reminds me of a couple times I went to the doctor when I was
feeling lousy, and as soon as I was in the office I felt great
again.... or then, the computer crash that will never happen when the
local "computer guru" comes by to check it out for you...

Well, I guess that's good. No bad news is good news, so I suppose we
should leave it at that!

Actually, the little "debug" box is a nice feature that I would
recommend leaving it in, unless it seems embarassing to you. It's so
small, it doesn't seem to bother anything. Then anybody can send you
a report in the future....

Also, I wouldn't take it back out, since it might start crashing
again
:) One never knows....

Thanks again!!!

_________ ___ __ _
Joseph

Hi Joseph,

>Well, you warned me that this might happen... Now that you included
>the "debug" code, the program works perfectly....

Do I understand you right, that with the debug code in, even when you don't
tick the box, it works fine?

If it only runs with the box ticked, that's no good because you will be making
huge log files all the time. Will also slow the program down considerably.

But if it runs with it unticked, that indeed will do no harm, and no appreciable
slowing down of the program - lots of sections that look like this:
if(debug_log)
{
...
}
which will just be skipped out.

Prob. adds a few K to length of the prog. but not much. In fact, just checked, it
adds 56 K.

>Actually, the little "debug" box is a nice feature that I would
>recommend leaving it in, unless it seems embarassing to you. It's so
>small, it doesn't seem to bother anything. Then anybody can send you
>a report in the future....

It's a possibility - could make it showable with some command such as
#dbg into the note time box.

In fact I've just done that now.

You show it using #dbg, and hide it with #ndbg, typed into the Sustain box.

As you say, it doesn't seem to bother anything much. If you have
ticked the option to skip fast notes when a fractal tune gets into
tiny micro-second notes, then you get a little message there saying
how many notes were skipped each time they are. That's all that
it is used for at present.

No, it doesn't embarass me - if Netscape can show a special dialog
box when it crashes, which you fill in to send them a bug report, then I don't mind
including a special debug feature in Fractal Tune Smithy.

>Also, I wouldn't take it back out, since it might start crashing
>again
>:) One never knows....

Well, since I haven't fixed anything, you may yet find it does crash, and if it does,
you can try to repeat the crash with the box ticked, and send the log file to me.

So can anyone else using the program, as you say. It is indeed an idea.

The next step would prob. take some time - one would now try including only
part of the debug code, say, just the line numbers without the info added to make
it more readable, and then if it still didn't crash, remove them from one section at
a time until it did.

I would really prefer to do a more thorough investigation, but if you are happy
with it like this, I can just leave it for now.

I will also go through that area of the program yet again, really really thoroughly,
keeping an eagle eye out for bugs to fix, before the release = it is really central to it
and must work pretty perfectly if the program is to be any good at all.

So now you will be able to use the new features. Especially, you can redo the midi
clips for the _recent_ VRML files if you want, in any voice and pitch, in broken chords / ordinary
chords, etc. (see beta download page for how to instructions if you haven't come
across it yet). It's very easy to do.

Basically, you just open the .ts file you find in the VRML folder, change the voice /
pitch as you like, then type a code such as #msc into the sustain box (that's the one
to use if you want to make chords, reduced into single octave). Wait for disk drive
to whirr a bit, and there they all are - just reload the VRML model to hear them!
:-)

Robert

--- In tuning@egroups.com, "Robert Walker" <robert_walker@r...> wrote:

http://www.egroups.com/message/tuning/16058

> Hi Joseph,
>
> >Well, you warned me that this might happen... Now that you
included the "debug" code, the program works perfectly....
>
> Do I understand you right, that with the debug code in, even when
you don't tick the box, it works fine?
>

Well, I did it last night, and, as I recall, the program worked
perfectly whether the "debug" box was checked or not!.. but I will
try it again this evening just to make sure.

>
> It's a possibility - could make it showable with some command such
as #dbg into the note time box.
>
> In fact I've just done that now.

Great... that will be a valuable feature for sending reports back to
you, obviously...

>
> You show it using #dbg, and hide it with #ndbg, typed into the
Sustain box.
>
>>
> >Also, I wouldn't take it back out, since it might start crashing
> >again
> >:) One never knows....
>
> Well, since I haven't fixed anything, you may yet find it does
crash, and if it does, you can try to repeat the crash with the box
ticked, and send the log file to me.
>

Absolutely. I swear to you, though, that before you put in the debug
code the beta crashed EVERY TIME! And with TWO DIFFERENT
installations from scratch!!

> The next step would prob. take some time - one would now try
including only part of the debug code, say, just the line numbers
without the info added to make it more readable, and then if it still
didn't crash, remove them from one section at a time until it did.
>

Is that really worth it?? With the box unchecked it really doesn't
affect much, as you say... Except now it doesn't crash!

> I would really prefer to do a more thorough investigation, but if
you are happy with it like this, I can just leave it for now.

Well, perhaps now the users can just "mess around" with it, and
report any anomalies...

>
> I will also go through that area of the program yet again, really
really thoroughly, keeping an eagle eye out for bugs to fix, before
the release = it is really central to it and must work pretty
perfectly if the program is to be any good at all.
>

Yeah... it would be pretty bad on first appraisal if what happened to
me happened to others who bought the license...

> So now you will be able to use the new features. Especially, you
can redo the midi clips for the _recent_ VRML files if you want, in
any voice and pitch, in broken chords / ordinary chords, etc. (see
beta download page for how to instructions if you haven't come across
it yet). It's very easy to do.
>
> Basically, you just open the .ts file you find in the VRML folder,

Great. I will try it.

Thanks again!

Joseph