From: "Peter Moylan" <ecs-isp@2rosenthals.com>
Subject: Re: [Weasel] I'm back
To: weasel-list@os2voice.org
References: <68e9f447.2.mr2ice.fgrirsq@earthlink.net>
Cc: eCS-ISP list <ecs-isp@2rosenthals.com>
Message-ID: <68EC7B69.3020004@pmoylan.org>
Date: Mon, 13 Oct 2025 15:09:13 +1100
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <68e9f447.2.mr2ice.fgrirsq@earthlink.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 11/10/25 17:08, steve53@earthlink.net wrote:
> In <68E9DFE1.9090307@pmoylan.org>, on 10/11/25
>     at 03:41 PM, Peter Moylan <peter@pmoylan.org> said:

>> I've done the first pass through pending mail, so I have a feel for what
>> I need to deal with. I think I'd better start with Doug's problem,
>> because a comment from Steven suggested that this might not be a pure
>> "out of memory" problem.
>
> I misread the stack the first time through.  Doug's problem had nothing to
> do wih memory.  Here's an annotated errinfo.$$$
>
> #RTS: unhandled exception #3: invalid location
> 000289FF  00000001  WEASEL.EXE  000389FF   OS2Sem_SemError+5F
> 000474A6  00000001  WEASEL.EXE 000574A6   TaskControl_Release+16
> 0001DB16 00000001  WEASEL.EXE 0002DB16HammerCheck_ClearPasswordError+B6
> TaskControl_Release
> 00031E0C  00000001  WEASEL.EXE 00041E0C   AUTH+38C> -> HammerCheck.ClearPasswordError
> 00031554  00000001   WEASEL.EXE 00041554SMTPCommands_HandleCommand+1F4->call esi
> 0004B168  00000001  WEASEL.EXE 0005B168   HandleCommand+38 ->SMTPCommands_HandleCommand
> 0004BB41  00000001  WEASEL.EXE 0005BB41
> 000477B7  00000001  WEASEL.EXE  000577B7
> 0000FB4B  00000001  XDS230M.DLL  0000FB4B
> 00020296  00000001  XDS230M.DLL  00030296

AARGH. HOW DO I TELL THUNDERBIRD NOT TO WRAP LINES?

> My current analysis says that the Obtain at
>
> HammerCheck.MOD:384
>          Obtain (HammerList.access);
>
> in ClearPassword failed because the DosRequstMutexSem in Obtain at
>
> TaskControl.MOD:655
>          status := OS2.DosRequestMutexSem (L, OS2.SEM_INDEFINITE_WAIT);
>
> terminated with ERROR_INTERRUPT (most likely).  This caused the
> DosReleaseMutexSem in Release at
>
> TaskControl.MOD:667
>          errno := OS2.DosReleaseMutexSem (L);
>
> to fail.

Thanks for the analysis. It was really needed, because I could make no 
sense at all of Doug's errinfo.$$$. Not his fault, but mine. I have a 
workplace in the XDS IDE called "WeaselOld", which is needed because bug 
reports usually are for a different version than my current version. I 
must have messed up something this time around, perhaps mixing sources 
from different versions or unzipping the wrong zip file.

I wrote the OS2Sem module precisely to handle the ERROR_INTERRUPT case. 
Looking at it again now, I see that the job is incomplete. I put all of 
my effort into the timed wait case, where you have to restart the wait 
with a different time limit. But in the case of an indefinite wait -- 
OK, I think I've done that correctly too, just repeating the wait after 
an ERROR_INTERRUPT. But it looks as if there are multiple cases in 
module TaskControl where I just call DosRequestMutexSem without checking 
for ERROR_INTERRUPT.

On top of that, it hadn't even occurred to me that an ERROR_INTERRUPT 
could happen when releasing a mutex. This is going to take a bit of 
work, to cover all cases.

> FWIW, I think you need two versions of Obtain.  One that returns status so
> that the caller can use the status to figure out how to proceed and a
> second version that invokes SemError to report mutex errors because the
> caller contains no error handling code.

At this stage I'm inclined to disagree with that. The cases that can be 
dealt with are the cones that OS2Sem handles. I can't think of any case 
where the caller could do anything sensible on failure.

Having OS2Sem.SemError do a hard crash is deliberate. A semaphore 
operation is so basic that it if fails the caller is in deep trouble. 
With a hard crash, at least you're able to do a post-mortem analysis. 
What is needed in this case is fixing the bug, not attempting to continue.

> If you implement this, you probably want to enhance SemError to report the
> failing operation along with the status.

I'm not sure I understand this. Do you mean reporting whether it was an 
"obtain" or a "release"? Or something higher-level, like identifying the 
caller? The latter would mean changing a lot of code.

-- 
Peter Moylan                  peter@pmoylan.org
http://www.pmoylan.org