**** BEGIN LOGGING AT Fri May 22 02:59:57 2020
May 22 03:52:40 <owrt-snap-builds> build #305 of mpc85xx/p2020 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp2020/builds/305
May 22 04:51:46 <owrt-snap-builds> build #327 of mpc85xx/p1020 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/327
May 22 05:11:25 <owrt-snap-builds> build #326 of imx6/generic is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/imx6%2Fgeneric/builds/326  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>, Hauke Mehrtens <hauke@hauke-m.de>, Philip Prindeville <philipp@redfish-solutions.com>
May 22 05:13:24 <owrt-snap-builds> build #317 of mxs/generic is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/mxs%2Fgeneric/builds/317  blamelist: Philip Prindeville <philipp@redfish-solutions.com>, Hans Dedecker <dedeckeh@gmail.com>, Hauke Mehrtens <hauke@hauke-m.de>
May 22 06:29:21 <owrt-snap-builds> build #307 of ath79/tiny is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny/builds/307
May 22 08:14:06 <owrt-snap-builds> build #119 of bcm27xx/bcm2708 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2708/builds/119
May 22 08:50:49 <jow> so two days have passed an no big explosions anywhere, seems 19.07.3 went quite smooth. Thanks to everyone involved
May 22 09:09:30 <Borromini> :)
May 22 09:09:45 <Borromini> is there an 18.06 point release planned as well? i thought there was gonna be both.
May 22 09:09:48 <Borromini> (out of curiosity)
May 22 09:20:46 <kristrev> I am very impressed by 19.07 in general, on the devices I run (ramips + x86) it has been rock solid since day one
May 22 09:27:35 <rmilecki> jow: except for netifd not (re)starting for me, yes, no explosions ;)
May 22 09:37:04 <rmilecki> can someone look with me at this line: https://lxr.openwrt.org/source/libubox/blobmsg.c#L147 please? is "len" variable used there correctly? jow?
May 22 09:45:35 <jow> rmilecki: sorry, the blob stuff is an incomprehensible maze to me
May 22 09:45:52 <jow> never sure whether I am dealing with a blob, a blobmsg, what len to use etc.
May 22 09:46:21 <rmilecki> i'm compiling libubox with s/len/blob_len(cur)/
May 22 09:46:33 <jow> oh yeah, and never sure what kind of iterator to use
May 22 09:46:48 <rmilecki> :P
May 22 09:46:49 <jow> the double underscore one or the simple one
May 22 09:49:19 <rmilecki> oh, not it went totally wrong
May 22 09:49:20 <rmilecki> [    7.160496] procd: Not starting instance ubus::instance1, command not set
May 22 09:49:36 <jow> that sounbds like a bug we fixed long ago
May 22 09:49:51 <jow> are you srure your builds are current? are you using official iamges?
May 22 09:49:56 <rmilecki> it's probably caused by my (incorrect?) libubox change
May 22 09:53:01 <zorun> rmilecki: I don't think libubox was changed between 19.07.2 and 19.07.3
May 22 09:53:19 <zorun> rmilecki: as far as I remember, there was a regression in 19.07.1, and it was supposed to be fixed in 19.07.2
May 22 09:53:21 <rmilecki> it has started with 19.07.2
May 22 09:53:42 <zorun> ah right, I understood that your issue appeared with 19.07.3
May 22 09:53:44 <rmilecki> right, that fix in 19.07.2 actually broke sth else ;)
May 22 09:55:39 <jow> rmilecki: what is blobmsg_check_array_len() purpose even?
May 22 09:55:51 <rmilecki> i have no idea
May 22 09:56:37 <jow> ah it seems to both ensure that all elemnts of the array are of a given type and that it somehow fits into a specific length
May 22 10:03:33 <jow> rmilecki: so the passed len is supposed to be the max length of the object, which supposedly comes from out of band information (e.g. the return value of a recv() or recvmsg() call)
May 22 10:04:22 <rmilecki> jow: what bothers me is that blobmsg_check_array_len() uses __blobmsg_for_each_attr() for iteration
May 22 10:04:28 <jow> rmilecki: the various inner function calls then check if their specific pice of the blob (header, data payload whatever) does not exceed that maximum data len to avoid overreads or overwrites
May 22 10:04:40 <rmilecki> and that __blobmsg_for_each_attr() I beleve uses len (AKA rem) for its own internal purpose
May 22 10:04:58 <jow> one should probably think of it as an "end pointer"
May 22 10:05:14 <jow> and it would help to call it "maxlen" or "bufferlen"
May 22 10:05:31 <jow> since "len" implies length of the blob itself
May 22 10:05:36 <jow> anyhow
May 22 10:34:37 <jow> rmilecki: meeting, need another 30m
May 22 10:34:56 <f00b4r0> heh, looking at your exchanges, libubox sounds like a lovely piece of completely undocumented software? ;)
May 22 10:35:48 <rmilecki> jow: i won't complain, having you looking at it is already great, i don't know blob stuff well enough, I didn't even know there is sth called bloblist
May 22 10:35:57 <rmilecki> *blobmsg_list
May 22 10:36:08 <zorun> f00b4r0: you mean https://openwrt.org/docs/techref/libubox + reading the code is not enough? :p
May 22 10:36:51 <f00b4r0> zorun: I mean that when _jow_ says he doesn't understand how to properly use some code, that clearly suggests the documentation of said code is suboptimal ;)
May 22 10:37:16 <f00b4r0> and quickly browsing through the code I see the only comments to be found are license boilerplates ;)
May 22 10:38:17 <rmilecki> there are some comments: https://lxr.openwrt.org/source/libubox/blobmsg.h
May 22 10:39:32 <f00b4r0> indeed. I stand corrected :>
May 22 10:44:56 <ynezz> rmilecki: can you dump that blob into file?
May 22 10:45:01 <ynezz> working/failing case
May 22 10:45:18 <ynezz> I can then take a look at it
May 22 10:45:35 <rmilecki> ynezz: let me try
May 22 10:45:51 <ynezz> what platform is that?
May 22 10:46:05 <rmilecki> bcm53xx
May 22 10:46:11 <ynezz> i've tried that restart loop yesterday in qemu x86/64 and no luck
May 22 10:46:47 <ynezz> hm, but this was on master, maybe I should try 19.07.3 image
May 22 10:47:38 <rmilecki> it may be hard to reproduce on different machine / hw / setup
May 22 10:47:46 <rmilecki> it seems to be some memory access thing
May 22 10:47:54 <rmilecki> i noticed I can almost never reproduce this on first boot
May 22 10:48:09 <rmilecki> I flash firmware, boot it, try 5-10 times = nothing
May 22 10:48:16 <rmilecki> reboot, try 1-3 times = failed restart
May 22 11:14:04 <rmilecki> ynezz: it's always the same blob bassed by procd sh script to procd over ubus
May 22 11:14:34 <rmilecki> ynezz: i grabbed it using PROCD_DEBUG=1 /etc/init.d/network restart 2>/tmp/procd-$(date "+%H%M").log
May 22 11:14:39 <rmilecki> all 3 files are the same
May 22 11:15:19 <ynezz> rmilecki: I mean in C, probably instance_fill_array
May 22 11:15:32 <rmilecki> https://files.zajec.net/openwrt/procd-111029.txt
May 22 11:15:42 <ynezz> I need that blob.bin :)
May 22 11:15:45 <rmilecki> ynezz: how to dump that?
May 22 11:16:26 <ynezz> I used to base64 encode those blobs in syslog
May 22 11:18:16 <ynezz> or just open/write into file, whatever you like
May 22 11:29:29 <ynezz> rmilecki: sorry, phone call http://paste.ubuntu.com/p/BVZQfGyW3R/
May 22 11:29:52 <rmilecki> ynezz: getting on it now!
May 22 11:30:14 <rmilecki> wtf, I need Ubuntu account to download as text?
May 22 11:30:19 <rmilecki> what's wrong with you ubuntu
May 22 11:31:41 <rmilecki> got it patching file service/instance.c
May 22 11:32:46 <ynezz> systemd, netplan, no raw paste, time to switch back to debian? :p
May 22 11:53:06 <Borromini> paste.debian.net :)
May 22 12:02:28 <rmilecki> ynezz: your patch stopped procd from failing, it's quite likely when dealing with such annyoing memory bugs
May 22 12:02:39 <rmilecki> i'm taking a break now, going to eat sth, rest a moment
May 22 12:02:47 <rmilecki> I'll be back working later / evening maybe
May 22 12:16:59 <ynezz> Borromini: already switched to sprunge.us
May 22 12:17:13 <stintel> I usually use github gists
May 22 12:17:19 <stintel> you can delete yourself when no longer needed
May 22 12:19:54 <Borromini> ynezz: yeah sprunge is nice.
May 22 12:20:07 <Borromini> as is ix.io, similar approach
May 22 12:58:00 <nick[m]2> why can u no longer access the buildprocess logs in packages openwrt repro? :/
May 22 13:00:23 <nick[m]2> Further I know should use my github name instead of my real name?
May 22 13:00:30 <nick[m]2> now*
May 22 14:37:47 <lynxis> hHauke: do you know any problems with musl 1.2?
May 22 14:37:54 <lynxis> *Hauke^
May 22 14:59:42 <netprince> I'm trying to figure out why the LEDs are missing in /sys/class/led on the netgear r6700v2 in master... would it be related to this in dmesg? mt7621-pci 1e140000.pcie: Parsing DT failed
May 22 15:09:47 <lynxis> netprince: not sure, but DT failure on pci is a problem which should be fixed.
May 22 15:11:11 <lynxis> netprince: if leds are missing it's most likely related to DT (device tree). Except the kernel modules for leds are missing.
May 22 15:12:50 <netprince> that is what I was thinking, kernel modules look ok
May 22 16:08:46 <Hauke> lynxis: some components need adaptation for musl 1.2
May 22 16:09:04 <Hauke> they changed the time handling to work after 2036 on 32 bit systems
May 22 16:09:32 <Hauke> lynxis: mangix looked into this
May 22 16:10:37 <Hauke> lynxis: there is also a problem wioth your mail server contact@openwrt.org can not forward you a mail
May 22 16:10:41 <Hauke> it is still trying
May 22 16:11:38 <lynxis> Hauke: which server is it?
May 22 16:47:04 <owrt-snap-builds> build #68 of ath79/mikrotik is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fmikrotik/builds/68  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>
May 22 16:47:47 <hbug> i try to exclude the parts from init, which are not necessary in container usage. e.g. i removed the symlinks from modules-boot.d
May 22 16:48:05 <hbug> but /etc/hotplug-preinit.json confuses me. what does it do?
May 22 17:04:27 <hbug> from preinit.c it looks like it forks an instance of procd as 'hotplug deamon' with /etc/hotplug-preinit.json as paramter and the the 'real' procd instance is started?
May 22 17:10:09 <hbug> plugd does not seem to be a deamon that persists?
May 22 17:24:01 <owrt-snap-builds> build #121 of bcm47xx/legacy is complete: Failure [failed dirupload]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Flegacy/builds/121  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>
May 22 17:32:53 * f00b4r0 wonders why slashdirt-02 seems to have intermittent resolving failures
May 22 17:33:28 <f00b4r0> of note, I upgraded bind9 on that network following CVE-2020-8616
May 22 17:59:43 <rmilecki> ynezz: please check this diff: https://pastebin.com/gr4yt4v9
May 22 18:00:31 <rmilecki> ynezz: this is log: https://pastebin.com/N06T7Xkg
May 22 20:17:35 <aparcar[m]> jow: did you read this comment about getting the public key of a signify signature? https://github.com/openwrt/openwrt/pull/2911#issuecomment-620842476
May 22 20:22:34 <f00b4r0> seems like github is borken again
May 23 01:02:54 <owrt-snap-builds> build #330 of lantiq/xrx200 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxrx200/builds/330
**** ENDING LOGGING AT Sat May 23 03:00:00 2020