How to find which object is causing an error

#1

Sorry if this is a dumb question.

I'm trying to run an old patch in axoloti 2.0 and I'm getting an error bc apparently math/log doesn't work

I'm not using the specific math/log object and I'm trying to find which object(s) are giving me the error.

Is there an easy way to do that?

thanks

#2

Either look at the feedback/log Axoloti gives you and see if you can make any sense of it.

Or you can remove objects one by one and go live each time after removing an object, until you find the one that breaks the patch.

And check log every time you remove an object, because maybe it is more than one object that gives an error. If there are more objects that give error and you remove one object that gives an error, the fail log should be shorter than when 2 objects giving error.

Fist option is probably the best. You could post the log here and maybe someone can tell you which object is making trouble. If there are errors, the developer would probably like to know, so they can fix it on Github.

#3

Thanks.

Yea I was trying the second but it's a fairly large patch.

Here's the log: the issue is already reported on github

section size addr
.text 32196 0
.rodata 11276 0
.data 4 0
.bss 12 0
.init_array 0 0
.fini_array 0 0
.comment 954 0
.ARM.attributes 57 0
Total 44499

Done compiling patch
Patch failed to load : failed to load patch
Can't find address for symbol logt (1)

#4

Cool.

That seems like an issue.

Sorry I can't make a lot out of it. But I can tag someone who might know :wink:

@thetechnobear @johannes

#5

Hmmm, maybe caused by 'USE_LINK_GC = yes' in the 2.0 firmware Makefile? In the older version, this was set to 'no'.

Anyway, the error message... logt is an array of log values, initialized during firmware startup. The name 'logt' has nothing to do with Axoloti object names.

#6

Ok thanks

I can try out tonight or tomorrow.

So I would change this and compile from source right?

I can figure out how to do that but I've never done it before so if anyone can enlightenment me how to do so in manjaro it would be much appreciated.

#7

Well, it's not that simple. Maybe.

If I was facing errors like this, I'd try building from source, with 'USE_LINK_GC = no', to see if it changed things.

BUT, I don't know if Johannes changed this compiler option because the new code requires it, and this bug would need to be solved in a different way.

I'm pretty sure 2.0 isn't really ready for general use, so I'd suggest just going back to the previous version.