Closed matteodelabre closed 3 years ago
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.
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
.
@matteodelabre Are you using the cable that came with the device?
Yes I am. I also tested with other cables and it does not seem to make a difference.
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.
@matteodelabre would you be able to test against the v2.1 branch to see if this behaviour is still exhibited?
Did a quick bisect and it seems like you fixed the issue with commit cabf05a97. Now it runs perfectly even when compiled with Toltec’s toolchain. Thanks!
@matteodelabre Perfect!
Describe the bug When built using Toltec’s
qt:v1.1
image, tarnish crashes with the following output:To Reproduce
docker container run -it --rm ghcr.io/toltec-dev/qt:v1.1
tarnish
.Expected behavior No crash.
Screenshots —
Version Information:
Additional context When building in debug mode (by passing
CONFIG+=debug
to qmake), the crash disappears. When building in release with debug symbols mode (withCONFIG+=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.