Hashlink access violation, when abstract is used as inerface

I am suffeing from a Access Violation error in hashlink.
In thx.core

Big.hx
public function multiply(that:BigIntImpl):BigIntImpl {
		if (that.isZero()) //<--- Excpetion here
			return Small.zero;
		return that.isSmall ? multiplySmall(cast that) : multiplyBig(cast that);
	}

BigIntImpl is a interface, and that is a BigInt abstract backed by the BigIntImpl, the method is being invoked by the * operator torough the abstract.

The base class is Big which extens BigIntImpl.

When I check it in the hashlink debugger it seems like that is now a simple int array hashlink debugger says Unknown value isZero.

How can I get past such a problem?

consider creating a small demo project that you can show people, so they can experience and test your issue and potentially suggest changes / possible fixes.
maybe in the form of a try.haxe.org link.

Since it is working in JS I made a github repo instead, after that I found that try.haxe.org has a hashlink oprion so I added both.

To my wonder, while trying to make a reroducable example, I bumped into another bug, to be sure I’ve tested it with neko and cpp both are working fine, hshlink is the outlier in both cases.

In javascript It is a normal practice to examine the js output and understand the haxe behavior, but with hashlink, I do not know how to do it, I tried to check with the hlbc GitHub - Gui-Yom/hlbc: Hashlink bytecode disassembler, analyzer, decompiler and assembler. gui but I wasn’t succesfull in understanding it.

A sensitive point, neko is said to be deprecated and hashlink to be mature, I agree about performance, utf8 and a more complete stdlib, but in regards to stability it needs some imporvement, I know that many commercial games are developed on it, so there must be solutions (step debugger on bytecode?) , but I do not know the right debug path.

Back to my question, I would be really thankfull if anyone could explain me why the isZero method is absent, exactly how hashlink is diffrent here, and what is the proper way to implement it in hashlink (If it is a hashlink bug, at least what the temporary work around is.

I think this might be the same or related problem as i experienced and made an issue for.

In short; if you extend an interface and “override” a method from the parent interface with a more specific return type it seems like hashlink gets things mixed up and try to use the wrong object signature or something like that.

The decompiler does not like the method thats causing my problem it seems (it shows invalid type).

Hey there,
It looks like you’re having trouble with an Access Violation error in hashlink when using the isZero() method on an object called that. Here’s how you can fix it:

  1. Check Types: Make sure that is the right type (a BigIntImpl object) and not a simple int array.
  2. Inspect that: Use the debugger to see if that is initialized correctly and has the right properties.
  3. Review Calls: Double-check how multiply() is being called to ensure that is passed correctly.
  4. Debugging Tools: Use hashlink’s debugging tools to track where that changes type.
  5. Error Handling: Add code to handle unexpected situations gracefully.

These steps should help you solve the Access Violation error.

that sounds a lot like something an AI would suggest. please don’t.

1 Like

Hi thanks for your time and effort to help me with this issue, its very valuable.

However as ablum already realized with his sharp eyes, the answer is incorrect except for the first paragraph It looks like… where the writer had a good approximation of the situation.

#1 I was very broad in my question about the type, #2 The debugger is mentioned in the question, #3 mention in questions, #4 ==2 #5 access violation cannot be handled gracefully.

In some forums AI is completely baned, I do not think so because sometimes AI cannot be fooled, where experianced humans could be fooled with a bad question, but the answers must be reviewed to see if the answer contains an Innovation, or if it is plain fluff stuff.

Anyway thanks for giving time for others issues, and thanks for keeping the value of human discussions above artificial multi word or multi sentance auto complete.