**** BEGIN LOGGING AT Tue Jul 03 03:00:00 2018 Jul 03 04:27:45 Morning Jul 03 06:23:03 Morning! Jul 03 06:23:18 morning Jul 03 06:28:14 bshah: it is quite unfortunate that I have to many difficulties reproducing that crash Jul 03 06:28:20 so* Jul 03 06:28:27 :( Jul 03 06:31:25 Tofe: can you help me with gdb session? I am unable to use gdb properly Jul 03 06:31:39 or well... Jul 03 06:31:54 unable to get proper backtrace for currentThreadData Jul 03 06:38:15 still this sigtrap issue? Jul 03 06:38:21 yeah Jul 03 06:39:28 I can try to help of course, though I'm no gdb genius Jul 03 06:41:01 well... at least better then me anyway :P Jul 03 06:41:14 so, steps I am doing just for reference Jul 03 06:41:35 gdb kwin_wayland Jul 03 06:41:53 b set_thread_data Jul 03 06:41:59 r Jul 03 06:42:04 step Jul 03 06:42:30 ... echo the address of currentThreadData and set watch point Jul 03 06:42:32 continue Jul 03 06:42:37 and then that's it Jul 03 06:42:41 it hits SIGTRAP Jul 03 06:54:22 so you set it on the first set_thread_data you encounter; does the thread number match the one of sigbus crash ? Jul 03 06:55:57 yes first thread Jul 03 06:57:09 this sigtrap is really annoying, I don't see anything obviously wrong here Jul 03 06:57:19 "It seems to be a matter of trying to access corrupted memory, which is caused by using an uninitialized dynamic library. By using the static (debug) versions of the boost::filesystem and boost::system library, and activating the -static switch for the linker, one can get rid of the problem." on stackoverflow Jul 03 06:57:55 it unlikely related to boost, but maybe it's related to an uninitialized dynamic library Jul 03 06:58:52 I guess we'll have to work around that "watch" functionality Jul 03 07:01:53 ah but wait: it seems you can just continue after a sigtrap? Jul 03 07:08:57 Tofe: but then I hit SIGSEGV and not SIGBUS Jul 03 07:09:36 ah, ok Jul 03 07:09:53 and if you don't set the watch, you still get sigbus, right Jul 03 07:10:23 without any watch or breakpoint on set_thread_data, yes SIGBUS Jul 03 07:16:07 even just the breakpoint triggers sigtrap? Jul 03 07:17:35 yep, just verified Jul 03 07:18:39 that's weird Jul 03 07:19:24 ... and really annoying Jul 03 07:19:58 maybe there's really a segfault ? Jul 03 07:21:22 https://stackoverflow.com/questions/15667795/how-can-i-make-gdb-stop-at-sigtrap-only-at-breakpoints/33498809#33498809 maybe we could just skip the sigtraps Jul 03 07:22:58 let's see Jul 03 07:23:41 oooh maybe what you can also try: break set_thread_data, r, step, set watchpoint, *remove breakpoint on set_thread_data*, continue Jul 03 07:23:56 if there's no breakpoint, maybe gdb won't watch int3 Jul 03 07:24:02 ah Jul 03 07:24:04 let's see Jul 03 07:24:18 that's excellent idea Jul 03 07:24:51 now, does it work :) Jul 03 07:27:10 that worked Jul 03 07:27:17 but well, https://ptpb.pw/0NCV Jul 03 07:27:43 the currentThreadData doesn't really get changed before sigbus Jul 03 07:31:58 can you load symbols for the sigbus backtrace ? Jul 03 07:32:29 sure Jul 03 07:33:58 Tofe: is backtrace : https://ptpb.pw/jFOe Jul 03 07:34:38 ah, no, I meant, where does 0xf5e933f4 point to Jul 03 07:34:47 also, I thought you were on aarch64 ? Jul 03 07:35:43 no I am not on aarch64, (well device is aarch64 sure but rootfs is armhf) Jul 03 07:36:02 and what do you mean by where does 0xf5e933f4 point to? (gdb noob) Jul 03 07:36:14 ah ok :) that might explain why I can't reproduce on my aarch64 halium-7.1. Or not. Jul 03 07:36:38 well, to what function in which library Jul 03 07:37:11 you can determine the library just by looking at /proc//maps Jul 03 07:37:49 okay Jul 03 07:37:59 then it's either a usual debug package to install or some android symbols Jul 03 07:38:23 that would be f5d43000-f5fb6000 r-xp 00000000 07:00 99860 /usr/lib/arm-linux-gnueabihf/libQt5Qml.so.5.11.1 I believe Jul 03 07:38:33 let me install debugsyms for qtdeclarative Jul 03 07:38:36 great, so it's just qtdecalarative-dbg Jul 03 07:43:32 weird Jul 03 07:43:42 despite installing symbols it shows crap backtrace Jul 03 07:45:29 some mismatch ? Jul 03 07:46:38 or, the backtrace really is corrupted. In which case it becomes very, very annoying Jul 03 07:47:50 mmh no, even with a faulty backtrace we would get an address somewhere (I think) Jul 03 07:48:51 yeah Jul 03 07:49:18 Morning! Jul 03 07:51:31 I am installing debug symbols for some more deps let's see Jul 03 08:01:54 hm installed almost all debug symbols still no luck Jul 03 08:04:37 hm Jul 03 08:21:36 I'm a bit out of idea right now... and surprised that the watchpoint didn't work Jul 03 08:23:10 np, and thanks for help so far Jul 03 08:31:18 this sigtrap might be interesting to investigate though Jul 03 08:31:42 it could be a memory corruption, maybe it's related to the sigbus Jul 03 08:32:28 bshah: do you have a backtrace of the sigtrap? Jul 03 08:32:53 it's same corrupted backtrace Jul 03 08:33:41 ah, bummer Jul 03 11:15:56 Tofe: I tried a thing, well I am sure it wouldn't work but tried neverthless, I replaced our bionic with the one from the mer-hybris (14.1 branch) it really didn't change anything tbh.. Jul 03 11:16:12 I also changed android_frameworks_native Jul 03 11:17:34 ok, well, was worth a try anyway Jul 03 11:18:13 I wonder if there would be an easy way for me to start kwin in luneos Jul 03 11:18:24 no Jul 03 11:19:03 but if you want I can provide you SSH access to my phone xD Jul 03 11:19:13 hehe Jul 03 11:19:22 well I wouldn't really know what to try **** ENDING LOGGING AT Wed Jul 04 03:00:04 2018