Error Request for Progress Review – ipurch DB Abnormal Shutdown with WebSpeed Memory Violation and APW/AIW Lock Stack Errors

Hi George ,I am not getting OpenEdge MONITOR Release 11

Database: /db/ipurchprod

1. User Control
2. Locking and Waiting Statistics
3. Block Access
4. Record Locking Table
5. Activity
6. Shared Resources
7. Database Status
8. Shut Down Database
9. Currently Connected Tenants

R&D. Advanced options
T. 2PC Transactions Control
L. Resolve 2PC Limbo Transactions
C. 2PC Coordinator Information

J. Resolve JTA Transactions

M. Modify Defaults
Q. Quit

Enter your selection: R&D


07/19/26 OpenEdge Release 11 Monitor (R&D)
10:57:58 Main (Top) Menu

1. Status Displays ...
2. Activity Displays ...
3. Other Displays ...
4. Administrative Functions ...
5. Adjust Monitor Options

Enter a number, <return>, P, T, or X (? for help): what to do next?
 
Yes George I got it thanks.
07/19/26 OpenEdge Release 11 Monitor (R&D)
11:13:35 This menu is not here Menu

1. Cache Entries
2. Hash Chain
3. Page Writer Queue
4. Lru Chains
5. Locked Buffers
6. Buffer Locks
7. Buffer Use Counts
8. Resource Queues
9. TXE Lock Activity
10. Adjust TXE Options
11. Latch Counts
12. Latch Times
13. I/O Wait Time by Type
14. I/O by File
15. Buffer Lock Queue
16. Semaphores
17. Shutdown
18. CDC Cache Info
19. BHT Latch Stats

Enter a number, <return>, P, T, or X (? for help): 11


07/19/26 Activity: Latch Counts
11:13:45 07/19/26 03:53 to 07/19/26 11:13 (7 hrs 20 min)

----- Locks ----- ------ Busy ------ Naps ---------- Spins ----------- ----- Nap Max -----
Owner Total /Sec /Sec Pct /Sec /Sec /Lock /Busy Total HWM

MTX -- 11801 0 0 0.0 0 0 0 0 0 0
USR -- 89 0 0 0.0 0 0 0 0 0 0
OM -- 868 0 0 0.0 0 0 0 0 0 0
BIB -- 195207 7 0 0.0 0 0 0 0 0 0
SCH -- 51 0 0 0.0 0 0 0 0 0 0
LKP -- 2017 0 0 0.0 0 0 0 0 0 0
GST -- 158747 6 0 0.0 0 0 0 0 0 0
TXT -- 15402 0 0 0.0 0 0 0 0 0 0
LKT -- 42818 1 0 0.0 0 0 0 0 0 0
LKT -- 42305 1 0 0.0 0 0 0 0 0 0
LKT -- 43155 1 0 0.0 0 0 0 0 0 0
LKT -- 41172 1 0 0.0 0 0 0 0 0 0
SEQ -- 66 0 0 0.0 0 0 0 0 0 0
AIB -- 961121 36 0 0.0 0 0 0 0 0 0
TXQ -- 15097 0 0 0.0 0 0 0 0 0 0

Enter <return> for more, A, L, R, S, U, Z, P, T, or X (? for help):
 
George, I also wanted to highlight one point. This issue is occurring only with this database. We have around 12 databases running on the same server with the same OpenEdge version, and they are not experiencing any similar issue. However, this particular database has gone down repeatedly over the last 2 days. Could this indicate a database-specific WebSpeed/client activity, memory stomp, or application code path issue rather than a general OpenEdge version issue?
 
Enter <return> for more, A, L, R, S, U, Z, P, T, or X (? for help): S
Sampling for 10 seconds ....

07/19/26 Activity: Latch Counts
11:39:32 07/19/26 11:39 to 07/19/26 11:39 (10 sec)

----- Locks ----- ------ Busy ------ Naps ---------- Spins ----------- ----- Nap Max -----
Owner Total /Sec /Sec Pct /Sec /Sec /Lock /Busy Total HWM

MTX -- 0 0 0 0.0 0 0 0 0 0 0
USR -- 0 0 0 0.0 0 0 0 0 0 0
OM -- 0 0 0 0.0 0 0 0 0 0 0
BIB -- 10 1 0 0.0 0 0 0 0 0 0
SCH -- 0 0 0 0.0 0 0 0 0 0 0
LKP -- 0 0 0 0.0 0 0 0 0 0 0
GST -- 0 0 0 0.0 0 0 0 0 0 0
TXT -- 0 0 0 0.0 0 0 0 0 0 0
LKT -- 0 0 0 0.0 0 0 0 0 0 0
LKT -- 0 0 0 0.0 0 0 0 0 0 0
LKT -- 0 0 0 0.0 0 0 0 0 0 0
LKT -- 0 0 0 0.0 0 0 0 0 0 0
SEQ -- 0 0 0 0.0 0 0 0 0 0 0
AIB -- 332 33 0 0.0 0 0 0 0 0 0
TXQ -- 1 0 0 0.0 0 0 0 0 0 0

Enter <return> for more, A, L, R, S, U, Z, P, T, or X (? for help):


07/19/26 Activity: Latch Counts
11:39:34 07/19/26 11:39 to 07/19/26 11:39 (10 sec)

----- Locks ----- ------ Busy ------ Naps ---------- Spins ----------- ----- Nap Max -----
Owner Total /Sec /Sec Pct /Sec /Sec /Lock /Busy Total HWM

EC -- 0 0 0 0.0 0 0 0 0 0 0
LKF -- 0 0 0 0.0 0 0 0 0 0 0
BFP -- 0 0 0 0.0 0 0 0 0 0 0
BHT -- 176 17 0 0.0 0 0 0 0 0 0
PWQ -- 0 0 0 0.0 0 0 0 0 0 0
CPQ -- 100 10 0 0.0 0 0 0 0 0 0
LRU -- 2 0 0 0.0 0 0 0 0 0 0
LRU -- 0 0 0 0.0 0 0 0 0 0 0
BUF -- 10 1 0 0.0 0 0 0 0 0 0
BUF -- 172 17 0 0.0 0 0 0 0 0 0
BUF -- 170 17 0 0.0 0 0 0 0 0 0
BUF -- 0 0 0 0.0 0 0 0 0 0 0
INC -- 0 0 0 0.0 0 0 0 0 0 0
CDC -- 0 0 0 0.0 0 0 0 0 0 0
SEC -- 0 0 0 0.0 0 0 0 0 0 0
LG -- 0 0 0 0.0 0 0 0 0 0 0

Enter <return>, A, L, R, S, U, Z, P, T, or X (? for help):
 
So BFP locks are zeroes - as expected.

[2026/07/18@07:46:28.611-0500] P-9536 T-140146538906048 I APW 0: (-----) user #: 0, usrinuse #: 0, (srvctl:srvctl) 0:0, latchId: 18
[2026/07/18@07:46:28.611-0500] P-9536 T-140146538906048 F APW 0: (-----) lock stack corrupt expected 18 was 0 sp 0

So it's not expected for latchId 18 to be mentioned in the errors.
 
I wonder George . I also wanted to highlight one point. This issue is occurring only with this database. We have around 12 databases running on the same server with the same OpenEdge version, and they are not experiencing any similar issue. However, this particular database has gone down repeatedly over the last 2 days. Could this indicate a database-specific WebSpeed/client activity, memory stomp, or application code path issue rather than a general OpenEdge version issue?
 
I wonder George . I also wanted to highlight one point. This issue is occurring only with this database. We have around 12 databases running on the same server with the same OpenEdge version, and they are not experiencing any similar issue. However, this particular database has gone down repeatedly over the last 2 days. Could this indicate a database-specific WebSpeed/client activity, memory stomp, or application code path issue rather than a general OpenEdge version issue?
Or rcode corruption, for example. Protraces point out that the same rcode and the same statement in rcode was running while the errors were issued.

But the best choice is to upgrade your Progress version first.
 
and also when db down when i did proutil -C dbipcs it was showing like this and other dbs was ok
425985 6413739 1 - /db/prod/mfprod.db 458754 6413739 0 Yes /db/prod/admpro.db 491523 6413739 0 Yes /db/prod/lpprod.db 524292 6413739 0 Yes /db/prod/csrod.db 557061 6413739 0 Yes /db/prod/ssbdpr.db 589830 6413739 0 Yes /db/prod/ustprod.db 622599 6413739 0 Yes /db/prod/qxe/qxeprod.db
720906 - - - (not PROGRESS) :- this one and was showing this :-

proutil ipurchprod -C holder
2
** The database ipurchprod is in use in multi-user mode. (276)
3

4
proutil ipurchprod -C busy
5
** The database ipurchprod is in use in multi-user mode. (276)
6

7
promon ipurchprod
8
The shared memory does not have the correct MAGIC number (1179)
 
Or rcode corruption, for example. Protraces point out that the same rcode and the same statement in rcode was running while the errors were issued. can i check with application team rcode can you suggest please what to check your valuable suggections please so it wont repeat again?
 
i got one article :-https://community.progress.com/s/article/looping-additions-to-longchar-variable-corrupt-memory-of-client-and-attached-database-causing-1179-error . is tat related to this?

Looping additions to LONGCHAR variable corrupt memory of client and attached database causing 1179 error​

Looping additions to LONGCHAR variable corrupt memory of client and attached database causing 1179 error

  • Jul 24, 2020
  • Knowledge
Title
Looping additions to LONGCHAR variable corrupt memory of client and attached database causing 1179 error
URL Name
looping-additions-to-longchar-variable-corrupt-memory-of-client-and-attached-database-causing-1179-error
Article Number
000154164
Environment
Product: OpenEdgeVersion: 11.6, 11.7.0, 11.7.1, 11.7.2, 11.7.3, 11.7.4, 11.7.5OS: All supported platforms
Question/Problem Description
Looping additions to LONGCHAR variable corrupt memory of client and attached database causing 1179 error
After the first 1179 there are no more logins
Client's fail to connect and new remote servers fail to start once shared memory cannot be attached
Steps to Reproduce
prodb x demoproserve x -B 212000mpro x -p x.px.p contains the code example below
Clarifying Information
DEFINE VARIABLE X AS LONGCHAR NO-UNDO.

OUTPUT TO x.txt PAGE-SIZE 0 UNBUFFERED.

ASSIGN X = FILL("X",128).

DO WHILE TRUE:
ASSIGN X = X + X.
PUT UNFORMATTED LENGTH(X) SKIP.
END.

OUTPUT CLOSE.

Error Message
The shared memory does not have the correct MAGIC number (1179)
Defect Number
Defect PSC00350346 / OCTA-20493
Enhancement Number

Cause
More memory can be allocated to a MEMPTR/LONGCHAR than is allowed (between 2 and 4 GB)

On UNIX systems, when this memory structure is cleared, the size is signed long with a negative number which then attempts to clear memory outside of the processes address space. In this case, it clears memory that is in database shared memory and this memory stomp results in the MAGIC number issue (1179)

On Windows, while greater than 2 GB can be allocated to a MEMPTR/LONGCHAR, the program cannot do anything with it as the buffer copy with fail.
Resolution
Upgrade to OpenEdge 11.7.6, 12.0 where the request input size is checked when allocating memory to a MEMPTR/LONGCHAR. If the input size is negative a message will be returned and terminate the session. This verification is performed on all supported Operating Systems:

Size of MEMPTR/LONGCHAR cannot exceed 2147483647 bytes (19208)
Workaround

Notes

Keyword Phrase

Last Modified Date
7/24/2020 2:24 PM



file_120.png

Files(0)

 
Or rcode corruption, for example. Protraces point out that the same rcode and the same statement in rcode was running while the errors were issued. can i check with application team rcode can you suggest please what to check your valuable suggections please so it wont repeat again?the identical ABL stack trace pointing to src/web/objects/web-disp.p line 775 and tptstart-new.p line 905. are these codes developed by app team ?or default? if appteam correct these will it on impact again on db?Can u suggest what i need to ask please?
 
Back
Top