PureBasic Forums - English

Mistrel wrote: Thu Sep 16, 2021 7:58 pm

jacdelad wrote: Thu Sep 16, 2021 7:40 pm Case closed.

No, it's not. What does the title of the topic say?

Thanks, Demivec. This was very helpful and informative. I was looking at "Handles and Numbers" in the documentation and didn't see the page you referenced.

This worked without issue in PureBasic (x86) but this may have been luck.

Demivec posted the part of the help that explained exactly what's happening. Case closed.

What does the title say?

Invalid memory access on DisableDebugger line when using very large numbers with CreateImage

This is a bug.

Why do you think it's OK for the debugger point you to a completely different line than where the problem occurred?

Mistrel wrote: Thanks, Demivec. This was very helpful and informative. I was looking at "Handles and Numbers" in the documentation and didn't see the page you referenced.

You're welcome. The information is found under 'PureBasic objects overview' which is listed just above 'Handles and Numbers' on the reference page.

Mistrel wrote: Thu Sep 16, 2021 9:29 pm Why do you think it's OK for the debugger point you to a completely different line than where the problem occurred?

What do you expect the debugger to do? You just disabled it! When something goes wrong, it points you to the last line it is aware of, which is the one with DisableDebugger.

Alright. That makes a lot of sense.

I still don't expect it to crash as a result, which it not a result of disabling the debugger but by how these functions handle being fed large numbers. The only reason I disabled the debugger at all was because of the warning which, as we've found can agree or conflict with the documentation.

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).

The debugger will only sometimes warn of numbers over 10,000. But the documentation states that numbers between 5,000 and 60,000 are "usually" valid (whatever that means). The bounds are not well defined but this summary does make it clear than arbitrarily large numbers are not well suited for static numbers.

The invalid memory access is probably a result of a memory allocation failure due to specifying an overly large number. The invalid access on the debugger line occurs because this is the last line where the debugger was active.

What is a valid input for an ID is very ambiguous but up to 5,000 at a minimum appears to be safe. I disagree with several of these implementation details but that would be more suited for a feature request and not a bug report.

Thanks for clarifying up some of the ambiguity for me, guys.