List(0) initialization causes loss of entities.

[norbert doerre]

There occurs an inconvenience with executing an entity break routine I wrote for my cad program. Function "EntitiesInsideFence(dpFence() as POINT2D, InsideH() as DWORD)" does not give back proper results when list "InsideH()" is not initialized with a number which exceeds the real found number of entity handles.
So, an initialization with for instance "ReDim InsideH(0)" ist not reliable. When 'InsideH() should give back exactly 5000 members in my example, the result may differ from about 4000 to 4500.
As soon as I use "30000" or similiar instead of "0" the result is proper.

FAULTY:
ReDim InsideH(0)
iCount = EntitiesInsideFence(dpFence(), InsideH())

CORRECT:
ReDim InsideH(30000)
iCount = EntitiesInsideFence(dpFence(), InsideH())

Is there any proposal or explanation?

[Michael Mattias]

REDIM'ing a one-element array with the subscript zero has worked correctly for me since 1991 using each of the PowerBASIC MS-DOS, Console and Windows (both 16- and 32-bit) compilers.

Fifty cents says your problem is in function EntitiesInsideFence, probably an error 1 (Programmer Error).

Make that fifty bucks.

But if you want to save your money and get someone to help you find your error, post the code for that procedure.

BUT FWIW, if EntitiesInsideFence() is not testing ARRAYATTR(0) (dimensioned yes/no) for the dpfence() array, that function will probably fail because dpFence() is never dimensioned. (Insufficient code shown).


MCM

[Brian Chirgwin]

It is hard to tell from what you posted. You need to post more code.

If you can make a simplified example that shows the problem others can take a look.

I've had code where it didn't work, but making a simple example to show the issue lead me to the error in my code. I've found most errors are mine and not in the PB compiler.

[norbert doerre]

May it be a timing problem?

The code producing this mysterious bug is the code of a DLL. It can't even be tested as an EXE because it is invoked by anoter DLL with events.
But my DLL-Debugger which is implemented inside the code of the DLL as an .inc file shows a correct number of items in the list and also correct values in the report. It only fails in real time access.
I have the impression that some data are lost during the real time process because it is very much math intensive because it breakes all kind of cad entities to the contour from inside of the fence of n posts. The fence itself can consist of any linear or nonolinear entities. The comparingly small source code has nevertheless 254 kB with nine .inc files and one .bas file. Therefore it is not possible to send more than a faulty result to this forum.
I also never noticed the bug before with any other applications. But perhaps some of You have an idea because You experienced a similiar situation. I only need a tip, not a solution.
Under which circumstances could it happen that an approved List_0() calculated inside one .inc file is tranferred with more or less loss of data to a function in another .inc file where the corresponding List_1() is intitiated correctly with Redim List_1(0)? But the transfer is running without any loss, when List_1() is initiated with Redim List_1(number greater than number of List_0()). A hint: The application uses only 29MB in memory w/o data, and there is no memory conflict.

[norbert doerre]

After rebooting the PC the conflict is eliminated???

As far as I could find out in the mean time, the DLL does also work fine with an initialisation of the list with List_1(0) after a reboot of the computer. But this causes a conflict with myself. ;-)
A DLL can only be invoked once, so there cannot be trouble with instances and old list data.
ArrayAttr(List_1(), 0) always gives back -1, under all circumstances.
I know I have to do some tests now...

[Dale Yarker]

How does InsideH(0) get redim'd INSIDE EntitiesInsideFence to make room for more members?

[norbert doerre]

                                do
                                        '
                                        '
                                        '
					If iEntKind <> %UNKNOWN Then
						EntH = mcGetHandle(iError)
						ReDim Preserve CrossingH(iCount + 1)
						CrossingH(iCount) = EntH
						iCount = iCount + 1
					End If
				Loop
			End If
		Next n
		ReDim dpSeg(0) 'zurücksetzen
	Next i
	Function = iCount
End Function

This is as smal section of code showing how I always do ReDim. You can see there is no doubt about the direct proximity to the action. The counter is never used outside of the code loop. Possible bugs of this kind are not possible. But there exists also no memory leaking with PB or caused by any code becase it is tested over many years.
Well, I found already out that after about 50 compilations of 250 KB source code the transfer ot data from one list to another is stopped after it reaches about 80 to 90%. After a reboot everything seems to be OK again.

[Michael Mattias]

"IF" you are using PB/DLL 6x for one module and PB/WIN 7x or 8x for the other module, REDIM'ing a passed array of UDTs does not work due to an undocumented change in the array descriptors between 6x and 7x.

But given "After a reboot everything seems to be OK again." it sure sounds like you are corrupting memory yourself somewhere. Try using #DEBUG ERROR ON when compiling your DLL and trapping Error 9 (Invalid subscript).

BTW...

You can see there is no doubt about the direct proximity to the action

Assuming your memory corruption error can be traced by the proximity of source code statements is an invalid assumption. Memory corruption is often not detected until much much later in your program, often in a seemingly "impossible" place relative to the source code. Trapping Error 9 WHEN IT OCCURS is the best way to find the actual error in your code.

MCM

[norbert doerre]

Trapping essential system errors

Michael, I've been trapping all essential system errors in a separate code file library since I began programming in 1971. It often helped with finding such or similiar bugs. But this time, there is no hint.
I just started the workstation, curious if the loss of data would happen again. All is appearently running fine currently. Tomorrow I'll send the DLL to my testing staff. Til the end of the week I'll know more.
For programming purposes, I'm even using by the way a completely purified and minimized XP prof w/o any software adds of MS to prevent unpredictionable errors.

[Michael Mattias]

Well, whatever is happening, I think I can tell you to stop looking at the compiler, because the problem is NOT with the compiler.

REDIM() and all the other array-manipulation functions have always worked perfectly for me, with the singular exception of that cross-version REDIM thing.

MCM

[norbert doerre]

No doubt about PB8 functionality!

I also have no doubt about the fine functionality of the PB8 compiler. It seems that cutting an each time different lot of data from being transferred from one list to another under exactly the same conditions could be an 'analog' problem in a digital device. ;-)
This morning again, everything is running well.
Perhaps there might be a few other programmers having been confronted with this phenomene before?

[Michael Mattias]

Yes, there have been many such phenomena [random memory corruption] reported here.

Other than programmer error, I think "reboot," "get rid of spyware" and "disable the anti-virus software" have corrected about 98 percent of the problems.

However, "programmer error" has proven the cause of such problems far more than the sum of the other three causes.


MCM

[Cliff Nichols]

Other than programmer error, I think "reboot," "get rid of spyware" and "disable the anti-virus software" have corrected about 98 percent of the problems.

BINGO!!!!....I ran into the same problem twice last week, simple examples, and could not get them to release the process so I could recompile. (Even though I could see the process leave the list in both "Windows Task Manager" and "SysInternals Process Viewer")....But worked for others that compiled the same code.

When I FINALLLLLlllyyyy tracked down this mysterious problem, it was my Anti-Spyware programs holding the process, but not showing in the list.

When the code is correct, and no one can see the problem, check your Anti-spyware /Antivirus tools first before claiming a problem with the compiler

[norbert doerre]

Date dependant with updates from MS???

Cliff, was it the first time You experienced that bug? I also noticed it just last week for the first time. But I don't use any antivirus or spyware protection on my development workstation. Protection is done remotely from time to time during the night or during pauses by the server. As long as I'm programming, any protection is switched off because I must be shure to use a pure XP system.
I also don't remember having received an update from MS last week. The problem is that the bug reveals here evidently with very large processes. I tested the DLL today a dozen of times, and all is still running fine. So I cannot reproduce it currently. On the other hand I don't appriciate it to come back again.

[Cliff Nichols]

Cliff, was it the first time You experienced that bug?

That particular one, yes. but then again my development machine pulls double duty (triple, quadruple, whathave you) because I get stuck between programming and putting on whatever "hats" needed at the moment (network admin/antivirus/printer probs....keeeeeeep going)

The problem being...I have to constantly guesstimate at "What Changed?" (barring what M$ changed without my knowledge...but thats another matter )

I also noticed it just last week for the first time.

I don't think any "Patch Tuesday" effects, unless you recently installed by hand rather than auto-update?

back to your original post

I wrote for my cad program.

which cad program?...any updates in say the last 2 weeks? (or further depending on how often you update?)

[norbert doerre]

Inconveniences which have nothing to do with PB.

Cliff, my DLL has been intensively tested by two other engineers since Monday, and the special bug I reported never apppeared on their machines. Only one of them told me that three concentric circles (of about 25000 entities) were not broken completely correct. There remains sometimes an arc (broken circles are arcs) of a (still) unreproduceable short length from outside to inside the breaking boundary. Using the same boundary several times under same conditions with the same bunch of circles, the result might look a bit different. Mostly (at 90%) the circles are exploded correctly to arcs. This is what I have still to work on. I'm shure I have first to explode them to a near 360° arc and then to break the arc to the contour. When circles with only one point on their contour are transferred to an arc during the DLL main break process, you cannot be shure if the resulting arc will be clockwise or non clockwise, because the construction point on the circle contour must somehow be "divided", and imagine that the "bigger part" of the point gives the direction of the arc. This is normally not significant with manual editing. But with this DLL, I have to consider from where to wherelse the break of circles is done in relation to the direction of the breaking contour, especially if the break results into more than one arc and when they all should have the same pregiven direction.
Sorry for my English, but I hope You can understand, even if this materia is far from PB.

According to the cad program, it has been developped since 1983 by myself - initially using Fortran on a Unix machine, and it has always been renewed until today using B... C++ and several PB compiler versions. So I'm the only one to control it's update service.

[Brian Chirgwin]

As far as I could find out in the mean time, the DLL does also work fine with an initialisation of the list with List_1(0) after a reboot of the computer. But this causes a conflict with myself. ;-)

Just yesterday I was working with EGrid Pro (great product) in virtual mode using a Tsunami database. I was reading a record based into a UDT array (0) on the row in the grid. At times the grid would display garbage characters.

I added Reset arrayname to the function which cleared the error.

I am not sure of the reason for the problem, but you might want to try performing a reset ArrayName and see if it clears the error.

In pseudo code the Egrid PRo event

Dim myUDT (0) as myUdtType

Reset myUDT() ' Without this garbage characters appeared in some cells. Also wasn't consistent.
GetDataFromTsunami ( myUDT, gridRow)
FillEachColumn

Function is called once for each cell in the viewable on screen.

I can't figure out why I had the problem.

[Michael Mattias]

Try using REDIM instead of DIM.

I think if you 'DIM' and the array is already allocated, it won't reset it.

DIM is a funny statement... it's either a compiler directive or an executed statement and I've never been able to figure out completely when it is what.

I use DIM() ... never.

I use ....

LOCAL|STATIC|GLOBAL arrayname()

.. to tell the compiler what "arrayname" is, and ..

 REDIM arrayname (number)

.. to actually create elements; I have had nothing but success that way.

MCM