From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,290f614236c91610,start
X-Google-Attributes: gid103376,public
From: Todd Rose <malibu@rahul.net>
Subject: Erroneous deadlock error w/Alsys Ada83 and SCO Unix (ODT 3.0)
Date: 1998/04/23
Message-ID: <353FA90B.74971BBB@rahul.net>#1/1
X-Deja-AN: 347082311
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Organization: EarthLink Network, Inc.
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1998-04-23T00:00:00+00:00
List-Id: <comp.lang.ada>


I'm having a problem with the Alsys Ada83 ver 5.52a compiler (Intel
platform) erroneously reporting Ada deadlocks. I've verified with Alsys
(now Aonix) that this problem has been reported by other users, but no
solution exists. Since both the compiler and OS is obsolete, I'm not
expecting much vendor support on this.

I've recompiled the application using an older compiler version (5.51)
and the problem occurs much less frequently, but still occurs rarely.

I am very sure that no "real" deadlock exist in the application, whether
or not they exsist in the runtime code - I don't know. In any case, the
deadlock indication is given when several tasks are clearly eligible for
execution - including tasks which are waiting at simple delay
statements.

Questions:

1) Has anyone experienced this problem and do you know what triggers the
deadlock message (other than a deadlock)?
2) Does anyone know of any solutions/workarounds?

Relevant info:

1) Approx 20,000 SLOC
2) Approx 40 active tasks. Most of the tasks are small semaphore or
monitor tasks. All task stack sizes are specified using 'Storage_Size.
3) "thin" interface (via pragma interface_c) with SCO's TLI socket API
and TSSnet TLI Decnet interface. All network calls are "non-blocking"
since the Alsys runtime executes under a single Unix proccess, no
threads in SCO 3.
4) Program reliability does seem to be affected by various kernal tuning
parameters, such as DMA and stream buffer allocations.
5) When caught in the debugger, the deadlock manifests itself by having
the entire Unix process go to sleep. No error indication or exception at
all.
6) No X window calls at all. All interfaces are through network
SOCK_STREAM sockets.

Suspected culprits:

1) Task stack overflows.
2) Unix signals being dropped.
3) Heap corruption.

Any help will be GREATLY appreciated, Thanks in advance..
-- Todd Rose