Crash accessing network menu on k3 #5780
Comments
Frenzie
changed the title
|
As an aside, the menu id not found warning is quite unlikely to be related to the segmentation fault. |
|
Oh, yeah, it's been there for a while (c.f., #4845). I'll see if I can get a usable backtrace... |
|
Also, obvious question is obvious: does it happen on the current stable/nightlies? |
|
Okay, I can repro. More info once I unfuck my GDB build ;D. |
Ping @poire-z ;). |
|
This is an older CPU, armv6 (i.MX35, arm1136JF-S), and that was built with the usual GCC 7.5 Linaro TC (in case it matters, since it seems to die in a gnarly GCC intrinsics). |
|
And in case the smaller screen helps reproducing this elsewhere: 600x800 (167dpi) ;). |
|
No real idea. --- a/frontend/ui/widget/textboxwidget.lua
+++ b/frontend/ui/widget/textboxwidget.lua
@@ -217,2 +217,3 @@ function TextBoxWidget:_measureWithXText()
if type(self.charlist) == "table" then
+ require("logger").warn("TextBoxWidget:_measureWithXText", self.charlist)
self._xtext = xtext.new(self.charlist, self.face, self.auto_para_direction,
@@ -225,2 +226,3 @@ function TextBoxWidget:_measureWithXText()
end
+ require("logger").warn("TextBoxWidget:_measureWithXText", self.text)
self._xtext = xtext.new(self.text, self.face, self.auto_para_direction,
diff --git a/frontend/ui/widget/textwidget.lua b/frontend/ui/widget/textwidget.lua
index c0ccac3c..11760ece 100644
--- a/frontend/ui/widget/textwidget.lua
+++ b/frontend/ui/widget/textwidget.lua
@@ -156,2 +156,3 @@ function TextWidget:_measureWithXText()
end
+ require("logger").warn("TextWidget:_measureWithXText", self.text)
self._xtext = xtext.new(self.text, self.face, self.auto_para_direction,
|
|
FWIW, switching to the STL atomics doesn't help. |
|
|
That would be the first entry, |
|
Disabling xtext obviously works ;). Disabling atomics entirely in HB also does it. diff --git a/src/hb-atomic.hh b/src/hb-atomic.hh
index f9afd4ff..783a4198 100644
--- a/src/hb-atomic.hh
+++ b/src/hb-atomic.hh
@@ -49,7 +49,7 @@
/* Defined externally, i.e. in config.h. */
-#elif !defined(HB_NO_MT) && defined(__ATOMIC_ACQUIRE)
+#elif !defined(HB_NO_MT) && defined(__ATOMIC_ACQUIRE) && defined(__NOPEY_NOPE)
/* C++11-style GCC primitives. */
@@ -72,7 +72,7 @@ _hb_atomic_ptr_impl_cmplexch (const void **P, const void *O_, const void *N)
}
#define hb_atomic_ptr_impl_cmpexch(P,O,N) _hb_atomic_ptr_impl_cmplexch ((const void **) (P), (O), (N))
-#elif !defined(HB_NO_MT) && __cplusplus >= 201103L
+#elif !defined(HB_NO_MT) && __cplusplus >= 201103L && defined(__NOPEY_NOPE)
/* C++11 atomics. */ |
|
@poire-z : Do you want to investigate or should I should apply that on kindle-legacy and be done with it? (EDIT: Probably on PB too). |
|
I don't feel like I can investigate anything :| That's some low level cooking you understand a lot more than me :) |
But... to go to |
|
Or there's some multithreading on that old Kindle ?! :) |
|
Yep, even though I went the quick route (i.e., startup, menu, left, left, ..., Network) ;). And, I hadn't really noticed because I was tail'ing post-crash, but this leads to... interesting results: |
|
(The QWERTYUIOP stuff is the non-touch labels for the keyboard shortcuts). |
|
Ooh, err, the WiFi callback happens to be asynchronous on Kindle, yeah, would that matter? |
|
Eh, the is_checked function just does a popen, I don't think the actual on-click callback should matter? |
|
If you disable that callback stuff in the code, and all works fine, well, it gets more interesting :) class XText {
private:
// Shared by all XText instances. Should not be used
// across calls to shapeLine()
static xtext_shapeinfo_t s_shape_result[MAX_LINE_GLYPHS];
static bool s_libunibreak_init_done;
public:and all the calls, measure, shaping, must be serialized - but Lua should ensure that, even if from multiple coroutines, only one should execute one call and wait before another can. Does that popen would do some UI/Text stuff? |
|
Nope, it basically returns 0 or 1 ^^. (Spoiler: always 0 on a K3 anyway ;p). |
|
And no issue on my PW2 on a 2019.12+ nightly, yeah. EDIT: (Where the is_checked function doesn't popen, though, it uses some native Lua bindings for the request). |
|
It's a keyboard device? No other KB device to see if it's a common thing with that kind? |
|
liblipclua ? That's not something we build, right? It's some own Kindle stuff, and they would use Lua ?! |
|
Yeah, it has a KB. And the only other KB device I have is also an older Kindle using the same CPU ;p. Flash UI doesn't change anything. And, yeah, that's lipclua. Everything since the K5 is using X with the awesome WM, which is written in Lua, so there's a bunch of Lua bits ;). |
|
And finally, NOP'ing the is_checked doesn't help ;). |
|
And, AFAICT, other menus w/ leading checkboxes are fine, both checked and unchecked. |
|
Well, no real idea. |
|
Is it normal that I'm seeing far more |
Workaround for koreader/koreader#5780
|
I see a lot of that on the emulator: which is white square with rounded corners (U+25A2) koreader/frontend/ui/widget/checkmark.lua Line 83 in e49198c |
* On Kindle legacy, disable atomics in HB Workaround for koreader/koreader#5780
Because apparently stuff blows up in weird and interesting ways for... reasons. Might be relevant on older PB devices, too? Re koreader#5780 Closes koreader#6024
* Ditch thread-safety in HB on LEGACY & PB to avoid weird atomics issues on armv6 koreader/koreader#6024 koreader/koreader#5780 * Don't ship glib on Kindle High kablooey potential, because we pull liblipc, which depends on it and libgthread, so we'd be mixing glib versions between the two... Regression since #1048
Issue
Steps to reproduce
Menu -> Network
crash.log(if applicable)crash.log
The text was updated successfully, but these errors were encountered: