 7.0.1762.4 gridmap iteration bug fix
#37553
05 Sep 24 11:36 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
OP
Member
|
|
OP
Member
Joined: Jun 2001
Posts: 11,794 |
|
|
|
|
Re: 7.0.1762.4 gridmap iteration bug fix
[Re: Jack McGregor]
#37556
06 Sep 24 08:04 AM
|
Joined: Sep 2003
Posts: 4,158
Steve - Caliq
Member
|
|
Member
Joined: Sep 2003
Posts: 4,158 |
Updated my local development, CS8 & CS8/64 - Thanks.
|
|
|
|
Re: 7.0.1762.4 gridmap iteration bug fix
[Re: Jack McGregor]
#37557
09 Sep 24 02:07 PM
|
Joined: Jun 2001
Posts: 3,406
Jorge Tavares - UmZero
Member
|
|
Member
Joined: Jun 2001
Posts: 3,406 |
Hi Jack, I've updated my development area and I'm getting memory errors while expanding XTREE. Below is the ashlog with XTREE debug active. This is a sequence of three xtrees launching but this is not a pattern, I've tried with other programs with three xtrees that don't crash, This sequence I can reproduce everytime but there were other random crashes that I'm trying to debug. So, probably there is not much help with this log and description but maybe you can guide me about what else to do or, if you want, connect here to check? Thanks
-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> noprams=13, file=
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> Array mode maxcnt = 0, bdatadescr = 0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> vwidth=34, maxcnt=0, textsz=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> Loading SftTree_IX86_U_75
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> XTREE begin: ctlno=-1, op=0, flags=814e221,0, tgt=0,0, t/l idx=0,0, navcd/msk=0x0/0x0, pos=1800,4000, par=17, max=0, icc=0, hwe=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> xtree: auto-assign ctlid 0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> xtree in: op=0, ctlno=0, active=0, par=17, trow/col=0,0, iaclick=0,0, lastxc=0, max=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> Coldef processing complete (15 ms)
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> Sorting col 1, order 1, ctrlkey=fffffc19, flags=80000000, colflags=401c0,1000000,0, rowidxcno=1
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> Sorting col 0, order 0, ctrlkey=fffffc19, flags=80000000, colflags=8001,0,0, rowidxcno=1
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> XTREE selrow = , key =
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> XTREE xtree_exit
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:13380> XTREE exit: rtncde: 0, extcod: 0 (0), xrow/col=0,0[0], trow/col=0,0, xvalid=0, navcod/mask=0x0/0x0, selrow=0, t/l idx=0,0, edit=0x0, icc=0, filt=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> noprams=13, file=
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> Array mode maxcnt = 0, bdatadescr = 0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> vwidth=55, maxcnt=0, textsz=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> XTREE begin: ctlno=-1, op=0, flags=814e221,0, tgt=0,0, t/l idx=0,0, navcd/msk=0x0/0x0, pos=1800,4000, par=14, max=0, icc=0, hwe=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> xtree: auto-assign ctlid 1
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> xtree in: op=0, ctlno=1, active=0, par=14, trow/col=0,0, iaclick=0,0, lastxc=0, max=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> Coldef processing complete (0 ms)
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> Sorting col 1, order 1, ctrlkey=fffffc19, flags=80000000, colflags=401c0,1000000,0, rowidxcno=1
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> Sorting col 0, order 0, ctrlkey=fffffc19, flags=80000000, colflags=8001,0,0, rowidxcno=1
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> XTREE selrow = , key =
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> XTREE xtree_exit
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:18bc7> XTREE exit: rtncde: 0, extcod: 0 (0), xrow/col=0,0[0], trow/col=0,0, xvalid=0, navcod/mask=0x0/0x0, selrow=0, t/l idx=0,0, edit=0x0, icc=0, filt=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> noprams=13, file=
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> Array mode maxcnt = 0, bdatadescr = 0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> vwidth=31, maxcnt=0, textsz=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> XTREE begin: ctlno=-1, op=0, flags=814e221,0, tgt=0,0, t/l idx=0,0, navcd/msk=0x0/0x0, pos=1800,4000, par=21, max=0, icc=0, hwe=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> xtree: auto-assign ctlid 2
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> xtree: expanding memory for new tree # 2
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> xtree in: op=0, ctlno=2, active=0, par=21, trow/col=0,0, iaclick=0,0, lastxc=0, max=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> Coldef processing complete (0 ms)
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> Sorting col 1, order 1, ctrlkey=fffffc19, flags=80000000, colflags=401c0,1000000,0, rowidxcno=1
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> Sorting col 0, order 0, ctrlkey=fffffc19, flags=80000000, colflags=8001,0,0, rowidxcno=1
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> XTREE selrow = , key =
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> XTREE xtree_exit
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:19989> XTREE exit: rtncde: 0, extcod: 0 (0), xrow/col=0,0[0], trow/col=0,0, xvalid=0, navcod/mask=0x0/0x0, selrow=0, t/l idx=0,0, edit=0x0, icc=0, filt=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:1ae09> noprams=13, file=
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:1ae09> Array mode maxcnt = 0, bdatadescr = 0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:1ae09> vwidth=353, maxcnt=0, textsz=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:1ae09> pansary=0144D204, cbansary=93000, maxcnt=0, cbanswidth=353, nullcount=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:1ae09> XTREE begin: ctlno=-1, op=0, flags=a14e221,1000, tgt=0,0, t/l idx=0,0, navcd/msk=0x0/0x0, pos=3000,2000, par=2, max=0, icc=0, hwe=0
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:1ae09> xtree: auto-assign ctlid 3
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:1ae09> xtree: expanding memory for new tree # 3
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:1ae09> ReAlloc XTREE#: old buffer at af74f50; new size 212576 bytes [fail] at 0 (Error=8)
09-Set-24 14:54:34 [UMZPOWER:03-3]<UZEMPRESAS:1ae09> !XTREE FATAL ERROR: unable to expand memory for new tree # (3)
Jorge Tavares
UmZero - SoftwareHouse
Brasil/Portugal
|
|
|
|
Re: 7.0.1762.4 gridmap iteration bug fix
[Re: Jack McGregor]
#37558
09 Sep 24 05:10 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
OP
Member
|
|
OP
Member
Joined: Jun 2001
Posts: 11,794 |
Hi Jorge -
The failure message (second from the bottom) is a direct result of a request to the Windows HelpReAlloc() function to request an increase in overall XTREE memory block (part of which is shared by all trees, but the rest of it is an array of per-tree allocations). So that would seem to suggest that the machine is running out of memory (unlikely when the request is only 212K), or more likely, that the memory heap has become too fragmented.
Of course, the fact that it starts happening after an update suggests some change in A-Shell's memory management. And in fact, awhile back I did switch from using GlobalAlloc() to HeapAlloc(), in the theory that the latter was more efficient. But I'm beginning to wonder if that improved efficiency comes at the cost of not being as robust. However, that change was made about a year ago, just before switching over from 6.5 to 7.0, so unless you were previously running on 6.5, that doesn't seem like the clear-cut trigger here.
It's not terribly difficult to switch between allocation methods, but it's not exactly trivial either, so we can't just throw a switch. (Because memory fragmentation and garbage cleanup have historically been chronic problems particularly affecting long-lived processes, A-Shell uses a layered approach of its own to try to minimize fragmentation and reduce dependency on garbage collection, which complicates the issue. And over time, both Windows and Linux has attacked the problem in their own ways, with Windows in particular adding all kinds of variations of its own, further complicating the overall picture.)
Assuming the problem is only happening in the XTREE reallocation (you may want to check your ashlog for other "ReAlloc" or "[fail]" instances), a possible simple workaround would be to increase the initial allocation from the current 2 to a number sufficient to handle as many trees as you may have in existence at any one time. (4? 24?). It would be somewhat wasteful though, for the average case.
Let me study this a bit more. If I can't reproduce it here, I may generate a test version that we can try in your environment to evaluate alternative strategies.
|
|
|
|
Re: 7.0.1762.4 gridmap iteration bug fix
[Re: Jack McGregor]
#37559
09 Sep 24 07:15 PM
|
Joined: Jun 2001
Posts: 3,406
Jorge Tavares - UmZero
Member
|
|
Member
Joined: Jun 2001
Posts: 3,406 |
Hi Jack,
No, definitely, this shouldn't be related to the HeapAlloc() switch, it's something between 7.0.1758.0c and 7.0.1762.4c, the former is my current stable release where the problem does not exist.
My guess goes to the release below but I didn't found time to download the previous and pos versions to test.
Does this rings some bell ?
If not, can you send those intermediate releases for me to test and confirm the exact one where the problem starts?
Thanks
============================================================================
A-Shell Release Notes Version 7.0.1761.2 (25 July 2024)
============================================================================
1. XTREE bug fix: XTREEs were getting unregistered at the end of a program
(including SBXs) leading to spurious invalid XTREE control errors when
re-entering an XTREE.
Jorge Tavares
UmZero - SoftwareHouse
Brasil/Portugal
|
|
|
|
Re: 7.0.1762.4 gridmap iteration bug fix
[Re: Jack McGregor]
#37560
09 Sep 24 09:13 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
OP
Member
|
|
OP
Member
Joined: Jun 2001
Posts: 11,794 |
You're probably right, although I hadn't yet figured out the connection or had a chance to reproduce it. (Typical busy Monday.) I was trying to approach it from first principles, i.e. a HeapReAlloc() to request 212K fails with error 8 (not enough memory). Which sounds like a memory fragmentation problem, but doesn't explain why it started happening recently.
In any case, I now have a test program to reproduce it so I should be able to get to the bottom of it shortly...
|
|
|
|
Re: 7.0.1762.4 gridmap iteration bug fix
[Re: Jack McGregor]
#37561
10 Sep 24 12:36 AM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
OP
Member
|
|
OP
Member
Joined: Jun 2001
Posts: 11,794 |
OK, I found a miscalculation in the memory allocation calculations, and also have introduced some further optimization to reduce the number of small buffer reallocations. (I haven't been able to test yet whether that made any measurable difference in the performance, but I'm no longer able to get the error, even after opening 20 XTREEs simultaneously. So I suggest you give this version a try... ash-7.0.1762.5-w32c-upd.zip
|
|
|
|
Re: 7.0.1762.4 gridmap iteration bug fix
[Re: Jack McGregor]
#37562
10 Sep 24 01:42 AM
|
Joined: Jun 2001
Posts: 3,406
Jorge Tavares - UmZero
Member
|
|
Member
Joined: Jun 2001
Posts: 3,406 |
You definitely found it, the two cases where I was able to produce the error are now working fine.
Many thanks
Jorge Tavares
UmZero - SoftwareHouse
Brasil/Portugal
|
|
|
|
Re: 7.0.1762.4 gridmap iteration bug fix
[Re: Jack McGregor]
#37563
11 Sep 24 12:03 AM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
OP
Member
|
|
OP
Member
Joined: Jun 2001
Posts: 11,794 |
The fix introduced a new issue though. It may not affect you, but if you ever create a new XTREE and specify a specific xtr.CTLNO that is beyond the highest tree number allocated so far, you may get a spurious "invalid tree #" error. That's fixed in 1762.6 ... ash-7.0.1762.6-w32-upd.zipash-7.0.1762.6-w32c-upd.zipash70notes.txtNote that it only affects the client (i.e. A-Shell/Windows or ATE, not A-Shell/Linux).
|
|
|
|
|
