Re: Continuing Mulberry-Windows issues

Ken,

This is super-helpful.   I am still mystified about why Mulberry
seems to work smoothly on several Windows machines but not on
the new one which should just be faster and with more memory,
but the answer to that one is probably "keep tinkering" and the
overall message may be "time to move on".  A few comments inline.

On Friday, 05 May 2023 11:42:52 -0700, Kenneth Porter
<[email protected]> wrote:

> --On Friday, May 05, 2023 2:41 PM -0400 John C Klensin 
> <[email protected]> wrote:
> 
>> These look like different errors to me and I have to admit I
>> have no idea what "Throw" or "Catch" mean in this context.
> 
> I suspect these can't be fixed without major surgery. I've
> seen the code  and it's quite hard to follow. One issue I ran
> into early is that Windows  code should try to run all its GUI
> logic in thread 1 but Mulberry started  as a Mac program and
> often tries to do GUI stuff in the worker threads, and  that
> has led to crashes.

Makes sense although, unless the attempted multithreading
introduces actual timing problems (new machine is a current
generation i7 while the others are i5s or worse and at least two
generations back), I'm still having trouble getting my head
around "works well on all the others running the same OS
version, etc., but not this one".

> The "throw" and "catch" are programming things. Old code would
> return error  codes when something went wrong. Newer code
> "throws" an object with  potentially complex information, like
> the name of the object (which is what  went wrong) and data
> associated with the error. Higher levels of the stack  can
> "catch" an exception and either do something about it, pass a
> different  exception with a different name with higher-level
> meaning, or just pass the  low level exception on. You'll see
> this idiom called try/catch, because the  catch applies to a
> whole block of code inside a try clause, and the throw  is the
> line that reports an error. Like this:
> 
> try {
>   it_failed = do_something();
>   if (it_failed) throw WhyItFailed;
> } catch (WhyItFailed) {
>   throw do_something_did_not_work;
> }

Ack.  And thanks.   Oddly (apparently) although the first
machine for which I wrote programs still had rotating main
memory, I had just never run into that particular terminology
before.  Probably just been away from the relevant communities
for too long and/or losing with my age.
 
> The exceptions you're seeing are out_of_range and
> CFileException. The first  one is usually a bad array index,
> like trying to access one more item than  an array actually
> has. That's often because one thread took an item off the  end
> while another thread was walking through the array looking at
> each  item, and they didn't coordinate their accesses. The
> file exception could  be attempting to access a file that
> doesn't exist, or writing to a  directory where one lacks
> permissions. Something file-related, in other  words.

Again, couldn't figure out why one machine and not all of the
others, but, as I think of it, the problem could easily be the
different in speed of the machines and the ability of the
current technology (including the i7) to handle more threads
than the machines of several years ago.  The other complications
is that, because of Windows file system changes some years back
(around Win 7 IIR), Mulberry thinks it is writing files to one
set of locations when in fact the they are ending up somewhere
else.  The good news is that has worked for years; the bad news
is that, in my experience, arrangements like that are fragile
and get worse over time.  Perhaps the "sometimes it writes and
crash dump and sometimes it cannot" could be part of that
picture too.

> c0000005 errors are memory access errors, and mean an attempt
> to read or  write memory that the program shouldn't. Which
> usually means a bad pointer,  often because the program got
> rid of an internal object and then tried to  access it again.

Good to know that is what c0000005 is.  I presume the memory
locations it gives are of no use whatsoever.  In any event, odd,
but not inconsistent with the above, especially if the "getting
rid of" happened in one thread and the access attempt was in
another.  I have never looked at the code, much less tried to
understand the internal logic, but the possible picture is
becoming more clear... maybe along with some surprise that the
now-ancient code, which I think Cyrus described as old and
outdated, has been stable and useful for this long.

Wishing I could retire or take an extended vacation from other
things and just rewrite Mulberry to modern standards, but that
isn't going to happen.  In the meantime, I should probably keep
tinkering, keep looking for a migration path that works for me
and my environment (web mail really doesn't), and maybe think
about whether I could run Mulberry in some sort of VM setup or
equivalent that would allow it to run at a more leisurely pace.

I'm exploring one migration alternative now; will report back
here if it turns out to be useful.

thanks again,
   john