tarnish crashes when built using Toltec’s toolchain

[matteodelabre]

Describe the bug
When built using Toltec’s qt:v1.1 image, tarnish crashes with the following output:

Creating DBusService instance
Looking for wireless devices...
  Checking lo...
    Not a wireless device
  Checking sit0...
    Not a wireless device
  Checking usb0...
    Not a wireless device
  Checking wlan0...
    Wireless device found!
Loading networks from settings...
Registering networks...
  Found network "Freebox_188"
  Found network "Freebox_188_5GHz"
Loaded networks.
Turning wifi on
Reconnecting to wifi
Wifi API false
Looking for batteries and chargers...
  Checking bq27441-0...
    Found Battery!
  Checking imx_usb_charger...
    Unknown type
Can't find charger information
terminate called without an active exception
Aborted (core dumped)

To Reproduce

1. Spin a Docker container with the Toltec qt image: docker container run -it --rm ghcr.io/toltec-dev/qt:v1.1
2. Download oxide v2.0-beta:

curl -L https://github.com/Eeems/oxide/archive/v2.0-beta.zip -o oxide.zip
apt-get -yqq update && apt-get -yqq install unzip
unzip oxide.zip

3. Build oxide using the linux-arm-gnueabihf-g++ spec file.

sed -i 's/linux-oe-g++/linux-arm-gnueabihf-g++/' applications/*/*.pro
make release

4. Transfer the result to the reMarkable and run tarnish.

Expected behavior
No crash.

Screenshots
—

Version Information:

• Device: reMarkable 1
• OS: https://github.com/orgs/toltec-dev/packages/container/package/qt v1.1
• Version v2.0-beta

Additional context
When building in debug mode (by passing CONFIG+=debug to qmake), the crash disappears. When building in release with debug symbols mode (with CONFIG+=release CONFIG+=force_debug_info), the crash comes back, and we can investigate further with gdb.

The problem may be thread-related, as terminate called without an active exception is the message given by the C++ standard library when a thread object that was not joined or detached gets destructed. But it could be something else.
When tracing the crash with gdb, it happens somewhere in the constructor of AppsAPI, but not always at the same line depending on whether you have an existing .config/Eeems/tarnish.conf file, which could indicate a race condition somewhere.
I’m unfortunately not able to switch threads with Entware’s gdb package to further investigate.

The only outstanding difference that I can see between the reMarkable-provided toolchain and the Toltec qt image is that the former contains gcc v7.3.0 and the later v8.3.0.

[Eeems]

Checking imx_usb_charger...
    Unknown type
Can't find charger information

Well that's interesting, I wasn't seeing that on my device. This could be related to the issue. Looking at my code, I don't expect it to fail if it fails to detect a charger, but I'd like to be sure. @matteodelabre what does cat /sys/class/power_supply/imx_usb_charger/type return for you?

The problem may be thread-related, as terminate called without an active exception is the message given by the C++ standard library when a thread object that was not joined or detached gets destructed. But it could be something else.
When tracing the crash with gdb, it happens somewhere in the constructor of AppsAPI, but not always at the same line depending on whether you have an existing .config/Eeems/tarnish.conf file, which could indicate a race condition somewhere.
I’m unfortunately not able to switch threads with Entware’s gdb package to further investigate.

I do have a couple places that read from the settings file, I might need to look into moving it to a single instance as it could be a timing issue between the threads.

[matteodelabre]

Checking imx_usb_charger...
    Unknown type
Can't find charger information

Well that's interesting, I wasn't seeing that on my device. This could be related to the issue. Looking at my code, I don't expect it to fail if it fails to detect a charger, but I'd like to be sure. @matteodelabre what does cat /sys/class/power_supply/imx_usb_charger/type return for you?

It reports USB_CDP.

[Eeems]

@matteodelabre Are you using the cable that came with the device?

[matteodelabre]

Yes I am. I also tested with other cables and it does not seem to make a difference.

[Eeems]

Interesting. It's reporting as USB for me, which is what I'm keying off of. I'll have to add USB_CDP as well.

[Eeems]

@matteodelabre would you be able to test against the v2.1 branch to see if this behaviour is still exhibited?

[matteodelabre]

Did a quick bisect and it seems like you fixed the issue with commit cabf05a. Now it runs perfectly even when compiled with Toltec’s toolchain. Thanks!

[Eeems]

@matteodelabre Perfect!