"Error: Access-Violation" while developing a GB32 Library...

[(X)]

PROBLEM:

I kept getting an error* when trying to develop  a GB32 library.  I narrowed it down to using a variable of unassigned type to which GB32 automatically assigns a Variant type.  Then, I checked that the error still manifests even if the Variant type is assigned manually.

* The "Error: Access-Violation" disappeared after assigning a type other than Variant.  Apparently, the Variant type does not work as expected in a GB32 library.

Dim dbg = 1  // or "Dim dbg as Variant = 1" Eventually returned "Error: Access-Violation"

SOLUTION:

This problem was resolved by assigning a specific type such as Single or Double.

Dim dbg as Single = 1

TAKE HOME MESSAGE: 

Be wary of a variable with an unassigned type when developing your GB32 libraries. 

OTHER COMMENTS:

Don't give up too easily.  Try starting from scratch or commenting out sections of code which is how I found the cause of this problem. Everything 'looked' OK but I found that unexpected behaviour was the culprit. 

I marvel at the fact that any computer system works at all and that we are dependant on more and more of these systems every day.

[scalion]

Le problème dans le développement des librairies est que les erreurs de violation peuvent survenir sans que cela ai un rapport avec le type de variable.
Il s'agit d'un véritable bug, j'en ai parlé avec Sjouke et il y a un problème structurel dans la compilation des librairies.
On peut très bien avoir un code qui plante à un endroit précis et il suffit d'insérer une autre procédure ailleurs dans le code qui n'a rien à voir pour que tout rentre dans l'ordre.
Pas d'explication pour l'instant .

[(X)]

Merci pour ces commentaires scalion.

Translation:

The problem in library development is that violation errors can occur without having anything to do with the variable type.
This is a real bug, I've talked to Sjouke about it, and there's a structural problem in compiling libraries.
You could very well have code that crashes in a specific place, and all you have to do is insert another procedure elsewhere in the code that has nothing to do with it, and everything will be back in order.
No explanation yet :(.    ~scalion

Translated with DeepL.com (free version)

Another tidbit from (X)

Je me souviens aussi que c'est parfois une bonne idée que la fin de la liste du programme soit une procédure Dummy(). Je ne sais pas si c'était uniquement pour les librairies.

---

I also remember that it's sometimes a good idea for the end of the program listing to be a Dummy() procedure. Not sure if that was for libs only.

[scalion]

Pour info,
I have just coded a small library for shaders, and I encountered the following problem:
"Error Access Violation etc..."

The problem in this case was the use of literal values:
a = 0.5 + 4.9999 * b / 3.141592 // cause error

To resolve this problem I declared local variables in the function:

local double c = 0.5
local double d = 4.9999
local double p = 3.141592

a = c + d * b / p // work fine !

I think it's an incorrect jump with litteral value when the expression is compiled.

[(X)]

I have been wrestling with this issue for years and trying to come up with an exact solution for: "What does and doesn't work in library code".

You might also get away with using a conversion function such as: Cdbl() for every literal. For example:

Local Double b = 1
Local Double a = Cdbl(0.5) + Cdbl(4.9999) * b / Cdbl(3.141592)