Code: Select all
image=CreateImage(#PB_Any,1,1)
DisableDebugger ; <- [ERROR] Invalid memory access
CreateImage(image,1,1)
Code: Select all
DisableDebugger ; <- [ERROR] Invalid memory access
CreateImage(23745977676672,1,1)
Code: Select all
image=CreateImage(#PB_Any,1,1)
DisableDebugger ; <- [ERROR] Invalid memory access
CreateImage(image,1,1)
Code: Select all
DisableDebugger ; <- [ERROR] Invalid memory access
CreateImage(23745977676672,1,1)
That's not what the debugger is telling me; it's providing a warning in the event that this is a bug and can be explicitly disabled. The code will compile fine and also run fine on PureBasic compiled for 32-bit. The bug occurs when compiling for 64-bit and the invalid memory access does not provide any information as to the cause and is indicated on a line separate from where the number is provided.
The only workaround is to either used fixed IDs or write a lot of extra code to allocate, track, and free my own list of dynamic IDs. I shouldn't have to do either of these things because #PB_Any does this for my already. Are either of those options a better programming style?
Code: Select all
DisableDebugger ; <- [ERROR] Invalid memory access
CreateImage(23745977676672,1,1)
There is no other way to do this without introducing performance penalties or adding a significant amount of workaround to reimplement #PB_Any.
You don't need to specify an unused ID when calling CreateImage().
I think you misunderstand. This is a bug. A very cursory look reveals even more problems.
Code: Select all
; [ERROR] #Image object number is very high (over 100000), are You sure of that ?
CreateImage(1000000000,1,1)
Code: Select all
; Works fine
CreateImage(1000000000,1,1)
Code: Select all
DisableDebugger ; <- [ERROR] Invalid memory access
CreateImage(10000000000000,1,1)
No. It's not normal. It's completely unexpected and causes the program to crash and an error to highlight on a completely different line.
There is an example linked in the original post.
What does this have to do with my bug report?
Code: Select all
DisableDebugger ; <- [ERROR] Invalid memory access
Define id=1
Repeat
CreateImage(id,1,1)
FreeImage(id)
id*2
; This bug is not a result of a negative number
If id<0
id=1
EndIf
ForEver
Looking at the help file you are running out of memory because you are using static indexing when creating your images. When a high index number is used PureBasic had to reserve all of the indexes from zero to that index number (i.e 23745977676672 as in your example code). I think you could predict that would cause problems and that it is not a bug and this behavior is documented in the help file.help file wrote: Indexed numbering
The static, indexed way, allows you to reference an object by a predefined numeric value. The first available index number is 0 and subsequent indexes are allocated sequentially. This means that if you use the number 0 and then the number 1000, 1001 indexes will be allocated and 999 (from 1 to 999) will be unused, which is not an efficient way to use indexed objects. If you need a more flexible method, use the dynamic way of allocating objects, as described in section II. The indexed way offers several advantages:
- Easier handling, since no variables or arrays are required.
- 'Group' processing, without the need to use an intermediate array.
- Use the object in procedures without declaring anything in global (if using a constant or a number).
- An object that is associated with an index is automatically freed when reusing that index.
The maximum index number is limited to an upper bound, depending of the object type (usually from 5000 to 60000). Enumerations are strongly recommended if you plan to use sequential constants to identify your objects (which is also recommended).
Numbers returned by using #PB_Any are not meant to be reused for object creation a second time. If they were then it would be static indexing that would be used and the problem of wasted indexes would occur as already mentioned.help file wrote:II. Dynamic numbering
Sometimes, indexed numbering isn't very handy to handle dynamic situations where we need to deal with an unknown number of objects. PureBasic provides an easy and complementary way to create objects in a dynamic manner. Both methods (indexed and dynamic) can be used together at the same time without any conflict. To create a dynamic object, you just have to specify the #PB_Any constant instead of the indexed number, and the dynamic number will be returned as result of the function. Then just use this number with the other object functions in the place where you would use an indexed number (except to create a new object). This way of object handling can be very useful when used in combination with a list, which is also a dynamic way of storage.
No, it's not. What does the title of the topic say?