**** BEGIN LOGGING AT Sat Oct 14 03:00:02 2017 Oct 14 07:47:37 Morning! Oct 14 07:49:21 Morning! Oct 14 08:46:44 Herrie: on my TP test_sensors works (build from 09.2016), so it's maybe hardfp/softfp issue indeed Oct 14 08:47:04 Herrie: could you try this change in libhybris? https://bpaste.net/show/06d3e91aa30e Oct 14 08:58:40 Morning guys Oct 14 09:00:19 nizovn: I've tried various combinations of *printf, but it seems that as soon as the android hardware lib is loaded, the va_args parsing is broken in glibc somehow for floats Oct 14 09:01:16 I'm quite surprised it's a "dynamic" thing, i.e. doesn't happen until something is executed... Maybe some unhooked thingy in libhybris, I don't know Oct 14 09:03:29 Tofe: I did go through that issue with krnlyng .. and he suggested me something but I never managed to find time to test that Oct 14 09:03:33 wait let me grep logs Oct 14 09:04:36 Tofe: see : https://ptpb.pw/Z4HT.log Oct 14 09:05:45 bshah: never heard of that hash option, I'll read a bit about it Oct 14 09:06:08 Tofe: can you grep for that option in halium 5 tree? Oct 14 09:07:06 bshah: sure Oct 14 09:10:08 there are occurrences in the kernel repos, prebuilt gcc binaries, and one occurrence in bionic (which isn't a test) which is "bionic/linker/linker.cpp: DL_ERR("empty/missing DT_HASH in \"%s\" (built with --hash-style=gnu?)", name); " Oct 14 09:10:36 so it seems it uses the default Oct 14 09:11:22 default would be... umm, gnu? Oct 14 09:11:38 "both", I guess, as linker would otherwise complain Oct 14 09:11:55 let me check Oct 14 09:12:19 bshah: but the issue we have doesn't look like a FPE, more like a va_args parsing issue to me Oct 14 09:12:41 unfortunately the corresponding glibc code is just a nightmare to read Oct 14 09:12:50 well.. for me it's FPE Oct 14 09:13:59 let's say it's both :p Oct 14 09:14:13 alternative facts :P Oct 14 09:15:02 anyway, I'm just surprised we don't have crashes in our user-space apps, only in the tests apps... Don't we ever use those float numbers ? Oct 14 09:15:37 "using" float numbers is fine.. just printf is what dies Oct 14 09:15:46 ah true Oct 14 09:16:48 bshah: the thing being a runtime issue is rather compelling; do you believe in a missing hook hypothesis ? Oct 14 09:17:52 Tofe: I think me and krnlyng completely crossed out that option Oct 14 09:18:04 ok Oct 14 09:18:37 it's good that this isn't an urgent issue... :) Oct 14 09:22:58 Tofe: so you got the sensorfwd fixed? Oct 14 09:24:17 bshah: nope, not yet... It's definitively a timing issue (it worked once, yesterday, after a cold boot, and didn't work after the reboot), there are some sem_wait failing involved, but I still don't know what's failing precisely Oct 14 09:25:45 everything is identical except errors like "E/libsensor1( 0): sensor1_open: Sem wait failed (err 0) for socket 16" Oct 14 09:26:11 ah wait, maybe libsensor1 is opensource? Oct 14 09:26:40 nope, qcom :( Oct 14 09:27:54 ah, there's a debug.qualcomm.sns.libsensor1=w, maybe I could play with this Oct 14 09:28:12 with "=d", and a bit of luck **** ENDING LOGGING AT Sun Oct 15 03:00:00 2017