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

Just starting out? Need help? Post your questions and find answers here.
User avatar
jacdelad
Addict
Addict
Posts: 1431
Joined: Wed Feb 03, 2021 12:46 pm
Location: Planet Riesa
Contact:

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

Post by jacdelad »

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.
PureBasic 6.04/XProfan X4a/Embarcadero RAD Studio 11/Perl 5.2/Python 3.10
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

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

Post by Mistrel »

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?
User avatar
Demivec
Addict
Addict
Posts: 4086
Joined: Mon Jul 25, 2005 3:51 pm
Location: Utah, USA

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

Post by Demivec »

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.
#NULL
Addict
Addict
Posts: 1440
Joined: Thu Aug 30, 2007 11:54 pm
Location: right here

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

Post by #NULL »

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.
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

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

Post by Mistrel »

:| :| :| :|

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. :)
Post Reply