MicroPython Forum (Archive)

Posted: **Thu Jul 07, 2022 9:54 am**

Good morning,
I seem to have found a possible bug in:
MicroPython v1.19.1 on 2022-06-18; Raspberry Pi Pico with RP2040

I reduced the code to just a few lines which show what happens.

Code: Select all

#!/usr/bin/env python3
import micropython
class Foo:

    @micropython.viper
    def __init__(self):
        self.foobar = 0
        return

    @micropython.viper
    def bar(self):
        self.foobar = 0  # looks like this line removes self.foobar from this instance
        return

foo = Foo()
foo.bar()  # works the first time
foo.bar()  # now throws exception: AttributeError: 'Foo' object has no attribute 'foobar'

Apparently the ›self.foobar‹ variable gets deleted but only when it's set to 0 in foo.bar()
Setting any other value works just fine.
Using the native decorator or no decorator at all works flawlessly.
Maybe someone can take a look and (if necessary) open a bug report (or point me to the correct place)

Thanks a lot.

Posted: **Thu Jul 07, 2022 10:54 am**

oint me to the correct place

The proper place for a bug report is the repository at https://github.com/micropython/micropython

Posted: **Thu Jul 07, 2022 12:14 pm**

Roberthh wrote: ↑
Thu Jul 07, 2022 10:54 am
The proper place for a bug report is the repository at https://github.com/micropython/micropython

OK, thanks. Maybe I'll create an account there as well and report.

Posted: **Thu Jul 07, 2022 2:07 pm**

Hello SilverBullet,

I could reproduce the Bug. Also on Blackpill with MicroPython v1.18-121-gd8a7bf83c.
But with slight difference:
If the __init(self)__ method has the @micropython.viper decorator the exception is raised already in the class instantiation (foo = Foo()).
If only bar(self) has this decorator, then foo first has member variable foobar and after the first foo.bar() statement this member is no longer there.
I tended to agree to conclude that viper class member methods that assign integer values 0 to member variables delete those variables.
But then found this:

Code: Select all

class Foo:
    @micropython.viper
    def __init__(self):
        self.v1 = 1
        return

    @micropython.viper
    def bar(self):
        self.v1 -= self.v1
        return

foo = Foo()
print(foo.v1)   # should print 1 but prints 0
foo.bar()
print(foo.v1)
foo.bar()
print(foo.v1)

The __init(self)__ function does not set the value 1 when decorated with @micropython.viper. Instead v1 is set to (or remains?) 0.
Removing this decorator lets it set v1 to 1 correctly.
Testing the above hypothetic conclusion I let compute an integer value of 0. But that seems to work correctly.
So the above conclusion is not correct. Only setting variable to 0 directly in viper mode seems to remove the variable.
Plus setting to any integer value is not working.
------
It may even hang up the system:

Code: Select all

class Foo:
    @micropython.viper
    def __init__(self):
        self.v1 = 1
        return

    @micropython.viper
    def bar(self):
        self.v1 -= self.v1
        return

    @micropython.viper
    def con(self):
        self.v1 = 4
        return

foo = Foo()
print(foo.v1)   # should print 1 but prints 0
foo.bar()
print(foo.v1)
foo.bar()
print(foo.v1)
foo.con()
print(foo.v1)

makes me loosing the connection in Thonny to both the Blackpill uPy 1.18 and RPi2040 uPy1.19.

Definitely a Bug to be reported in GitHub. If you prefer, I can report it. But first thank you for finding it and reporting here in the first place.

Greetings,
Raul

Posted: **Thu Jul 07, 2022 2:45 pm**

rkompass wrote: ↑
Thu Jul 07, 2022 2:07 pm
Definitely a Bug to be reported in GitHub. If you prefer, I can report it. But first thank you for finding it and reporting here in the first place.

Hi Raul,
Thanks for putting all that work in. Good to see that it's now confirmed.
Regarding the GitHub report: If it's not to much work, yes, please go ahead.

Posted: **Fri Jul 08, 2022 6:50 am**

rkompass wrote: ↑
Thu Jul 07, 2022 2:07 pm
I tended to agree to conclude that viper class member methods that assign integer values 0 to member variables delete those variables.

Yep. What's happening here is that something is going wrong with the small integer encoding for viper.

(In MicroPython, an object is a represented by an mp_obj_t which is an integer type that can either be a pointer to an object, a small integer, or a interned string. (and sometimes a float). See https://github.com/micropython/micropyt ... nfig.h#L94

When this code is compiled, it's trying to set self.foobar to 0, whcih should be encoded as the small int representation of zero, which is 1. But instead it's actually setting it to 0, which is interpreted as "NULL".

This bug is actually a lot worse -- all integers are being encoded incorrectly.

I will either fix it today and send a PR, or raise an issue at github today with more info.

TheSilverBullet wrote: ↑
Thu Jul 07, 2022 9:54 am
I seem to have found a possible bug in:
MicroPython v1.19.1 on 2022-06-18; Raspberry Pi Pico with RP2040

Thanks for the report!

Posted: **Fri Jul 08, 2022 7:08 am**

jimmo wrote: ↑
Fri Jul 08, 2022 6:50 am
This bug is actually a lot worse -- all integers are being encoded incorrectly.
I will either fix it today and send a PR, or raise an issue at github today with more info.
Thanks for the report!

You're welcome. And thanks for YOUR work. That's a great community here!

Posted: **Fri Jul 08, 2022 8:57 am**

jimmo wrote: ↑
Fri Jul 08, 2022 6:50 am
...
This bug is actually a lot worse -- all integers are being encoded incorrectly.
...

Could this be related?

Posted: **Fri Jul 08, 2022 12:43 pm**

pythoncoder wrote: ↑
Fri Jul 08, 2022 8:57 am
Could this be related?

Yep, looks like it. Thanks Peter!

Posted: **Fri Jul 08, 2022 2:14 pm**

Sent a PR to fix this: https://github.com/micropython/micropython/pull/8888

Unfortunately it turns out to be not quite the same as Peter's issue, but that's a little bit more difficult... this one was a good warm-up

MicroPython Forum (Archive)

possible bug with viper code in class

possible bug with viper code in class

Re: possible bug with viper code in class

Re: possible bug with viper code in class

Re: possible bug with viper code in class

Re: possible bug with viper code in class

Re: possible bug with viper code in class

Re: possible bug with viper code in class

Re: possible bug with viper code in class

Re: possible bug with viper code in class

Re: possible bug with viper code in class