Mailing List ecs-isp@2rosenthals.com Archived Message #1239 previous message next message back to list

From: "Peter Moylan" <ecs-isp@2rosenthals.com> Full Headers
Undecoded message
Subject: Re: [Weasel] I'm back
Date: Mon, 13 Oct 2025 15:09:13 +1100
To: weasel-list@os2voice.org
Cc: eCS-ISP list <ecs-isp@2rosenthals.com>

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
Subscribe: Feed, Digest, Index.
Unsubscribe
Mail to ListMaster