--- Log for 06.08.121 Server: erbium.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 1 day and 16 hours ago 00.40.38 *** No seen item changed, no save performed. 02.40.39 *** No seen item changed, no save performed. 03.14.10 Quit wolfshappen_ (Ping timeout: 258 seconds) 03.28.11 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 04.27.22 Quit Maxdamantus (Ping timeout: 240 seconds) 04.40.43 *** Saving seen data "./dancer.seen" 05.21.51 Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) 05.25.52 Quit advcomp2019_ (Ping timeout: 272 seconds) 05.31.18 Join Maxdamantus [0] (~Maxdamant@user/maxdamantus) 06.40.47 *** Saving seen data "./dancer.seen" 07.45.50 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 08.40.49 *** No seen item changed, no save performed. 09.00.34 Quit massiveH (Quit: Leaving) 09.08.06 # https://git.rockbox.org/cgit/rockbox.git/tree/firmware/logf.c#n303 09.08.45 # wtf is that (MAX_LOGF_SIZE-1) doing in there? 09.13.35 # <_bilgus> maybe the log is backwards? 09.14.19 # <_bilgus> that would push the pointer to the end of the buffer but seems wrong.. 09.14.43 # as in, what does that actually do? it evaluates as a cast 09.14.54 # (MAX_LOGF_SIZE-i) &logfbuffer[i + 1] 09.15.19 # ie (16383) &logfbuffer[i+1] 09.15.26 # in a format string 09.15.32 # I'm a bit confused too 09.16.32 # <_bilgus> OH is it supposed to be the size specifier? 09.16.41 # I think it might have been a leftover from a snprintf() but instead of dropping the max length they got rid of the comma 09.16.47 # <_bilgus> yep 09.16.53 # there is no size specifier to lcd_putsf() 09.17.22 # (I've been trying to make sense of the pair of read-beyond-array-end issues in this code 09.17.26 # <_bilgus> must be in a usually dead codepath? 09.17.50 # no, logf_panic_dump() -- which I know I've personally triggered many times :) 09.17.52 # <_bilgus> yeah, #ifdef ROCKBOX_HAS_LOGDISKF 09.18.25 # no, it's not in the LOGDISKF section 09.18.25 # I don't like what git blame says about who committed that 09.20.25 # <_bilgus> :p 09.20.57 # <_bilgus> yeah its in the !pctool part WEiRD 09.20.57 # There's a point in every maintainer's life where you've been working on a codebase long enough that the answer to "what idiot committed that?" is yourself. 09.21.47 # <_bilgus> I guess its a read so itd just be garbled data 09.22.03 # potentially a lot since we can't depend on null termination 09.22.24 # <_bilgus> maybe next build o coverity needs logf 09.23.21 # this issue it found is legit though 09.23.29 # At this point the only thing that means to me is a bitwise and, but that makes no sense... 09.24.33 # I don't do enough C these days... 09.24.38 # basically this can trigger if you _just_ wrap the logf buffer (ie the final character in the buffer is real, and the \0 gets wrapped to the beginning. 09.25.01 # (the overflow, not the wtf construct) 09.26.33 # make that "the final element in the buffer is \0" 09.29.30 # * gevaerts claims that wtf bit of code is clearly correct, because two people reviewed it 09.34.22 # maybe I'm being particularly dense today but it seems logf_panic_dump() is simply broken when it comes to wrapped buffers 09.35.06 # It's not the most commonly run code 09.35.20 # So that wouldn't actually surprise me at all 09.36.00 # we should run the if(logwrap) section first to dump the oldest stuff, _then_ then dump from the start of the buffer. 09.43.06 # tbh this whole thing seems a lot more complicated than it needs to be. 09.43.17 # panic_dump just needs to blindly dump out the logf buffer. 09.45.41 # if (wrapped) { dump(logfindex); } dump(logf_buffer); 09.46.23 # logfindex-1 is the \0 terminator, and is guaranteed to be there if anything has been written to the buffer. 09.48.31 # just need to ensure logfbuffer[size+1] is also \0 09.50.33 # aaah, now I get it; ok, it's a line-by-line dump intentionally. 09.52.19 # so the "fix" seems to consist of just bumping the buffer by 1 and making sure that padding is null-terminated. 09.59.30 # I'd appreciate a look at g#3661 please 09.59.32 # 3Gerrit review #3661 at https://gerrit.rockbox.org/r/c/rockbox/+/3661 : 3logf: Fix multiple issues with logf_panic_dump() by Solomon Peachy 10.00.00 # hopefully I didn't make things worse 10.03.13 Join cockroach [0] (~blattodea@user/cockroach) 10.03.32 # "highly questionable" is a nice euphemism there :) 10.04.41 # logf_panic_dump() is probably of little practical use unless there's very little in the buffer.. since the lcd code won't wrap the screen if there are more log entries than lcd rows 10.05.30 # ... wait. that's why it's backwards. bad peachy 10.05.51 # I'll fix that 10.08.38 # ok, updated. 10.08.56 # See, despite all the evidence to the contrary, that original code had *some* thinking behind it :) 10.28.13 Quit _bilgus (Quit: Leaving) 10.40.53 *** Saving seen data "./dancer.seen" 11.00.56 Quit rogeliodh (Quit: The Lounge - https://thelounge.chat) 11.01.38 # Build Server message: 3New build round started. Revision 835d0c737a, 303 builds, 10 clients. 11.01.45 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) 11.13.12 # Build Server message: 3Build round completed after 694 seconds. 11.13.14 # Build Server message: 3Revision 835d0c737a result: All green 11.38.26 Join amachronic [0] (~amachroni@user/amachronic) 11.47.22 # Build Server message: 3New build round started. Revision 34fcea0b20, 303 builds, 10 clients. 11.56.40 # Build Server message: 3Build round completed after 558 seconds. 11.56.42 # Build Server message: 3Revision 34fcea0b20 result: All green 12.10.43 # Build Server message: 3New build round started. Revision 6b1b7b6016, 303 builds, 10 clients. 12.20.52 # Build Server message: 3Build round completed after 609 seconds. 12.20.55 # Build Server message: 3Revision 6b1b7b6016 result: All green 12.40.54 *** Saving seen data "./dancer.seen" 14.22.55 # Build Server message: 3New build round started. Revision b8b195a296, 303 builds, 10 clients. 14.32.19 # Build Server message: 3Build round completed after 564 seconds. 14.32.21 # Build Server message: 3Revision b8b195a296 result: All green 14.32.24 # Build Server message: 3New build round started. Revision 1a9a5fc279, 303 builds, 10 clients. 14.40.58 *** No seen item changed, no save performed. 14.41.59 # Build Server message: 3Build round completed after 575 seconds. 14.42.02 # Build Server message: 3Revision 1a9a5fc279 result: All green 14.42.04 # Build Server message: 3New build round started. Revision d541a72a0e, 303 builds, 10 clients. 14.51.01 # Build Server message: 3Build round completed after 537 seconds. 14.51.04 # Build Server message: 3Revision d541a72a0e result: 0 errors 75 warnings 14.51.06 # Build Server message: 3New build round started. Revision 02b940396b, 303 builds, 10 clients. 15.00.33 # Build Server message: 3Build round completed after 568 seconds. 15.00.35 # Build Server message: 3Revision 02b940396b result: 0 errors 75 warnings 15.00.38 # Build Server message: 3New build round started. Revision 257ba1d2e0, 303 builds, 10 clients. 15.10.02 # Build Server message: 3Build round completed after 565 seconds. 15.10.05 # Build Server message: 3Revision 257ba1d2e0 result: 0 errors 75 warnings 15.10.08 # Build Server message: 3New build round started. Revision 2008b7d1b0, 303 builds, 10 clients. 15.19.28 # Build Server message: 3Build round completed after 560 seconds. 15.19.30 # Build Server message: 3Revision 2008b7d1b0 result: All green 15.51.42 Quit amachronic (Ping timeout: 276 seconds) 16.15.11 Join bilgus_ph [0] (~bilgus_ph@172.58.203.90) 16.17.14 # I found some interesting code in the metadata files I marked them pending if anyone feels like yay or nay-ing might require a bit of sleuthing 16.18.50 # Like the code to read an int32 64 etc it doesn't init cars and no check for errors but maybe that's for speed? 16.19.22 # Init variables *vars* 16.19.57 Quit bilgus_ph (Client Quit) 16.41.00 *** Saving seen data "./dancer.seen" 17.18.09 Join Bobathan [0] (~admin@cpe-65-29-248-157.wi.res.rr.com) 17.24.14 # amachronic: https://dl.linux-sunxi.org/users/tom/musbmhdrc_pspgUSB.pdf 17.24.50 # no wait, wrong one. 17.25.11 # (was a beast to find all the same...) 17.36.08 Quit ZincAlloy (Quit: Leaving.) 18.41.01 *** Saving seen data "./dancer.seen" 19.52.09 Join _bilgus [0] (~bilgus@162.154.213.134) 20.04.49 Quit Bobathan (Quit: ZNC 1.7.2+deb3 - https://znc.in) 20.06.46 Join dconrad [0] (~dconrad@208.38.228.17) 20.20.12 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 20.41.04 *** Saving seen data "./dancer.seen" 20.44.42 # 32-bit SW Vol: it kinda works this time! g#3669 20.44.44 # 3Gerrit review #3669 at https://gerrit.rockbox.org/r/c/rockbox/+/3669 : 3Higher-bit SW Vol, take three by Dana Conrad 20.44.59 # it's, uh, got a couple issues tho haha 20.45.09 # plays audio tho 21.06.02 # Build Server message: 3New build round started. Revision 8a8fd3d4a3, 303 builds, 9 clients. 21.07.15 # scale_buffer_trans clips to 16 bit 21.08.14 # ah, I'll try just commenting out the clip_sample_16() 21.11.05 # yup, good catch 21.17.00 # Build Server message: 3Build round completed after 658 seconds. 21.17.06 # Build Server message: 3Revision 8a8fd3d4a3 result: All green 21.41.32 Quit massiveH (Quit: Leaving) 21.47.15 # oh, I guess in pcm_sync_pcm_factors() the pcm_scaling_fn should be hardcoded to pcm_scale_buffer_cut 21.47.18 # makes sense 22.02.23 Quit cockroach (Quit: leaving) 22.13.41 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 22.23.18 # ok, made the mailing list and forum announcement about the downtime. 22.24.14 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) 22.39.20 # <_bilgus> speachy got a moment to look at something for sanity? 22.39.25 # sure 22.40.44 # <_bilgus> g#3671 22.40.46 # 3Gerrit review #3671 at https://gerrit.rockbox.org/r/c/rockbox/+/3671 : 3metadata/smaf.c hand;e read errors by William Wilgus 22.41.08 *** Saving seen data "./dancer.seen" 22.42.15 # _bilgus: s/;/l/ 22.42.30 # <_bilgus> yeah I saw that 22.42.57 # <_bilgus> kinda inbetween drywall sheets and hoped someone else could look i'm testing it atm 22.44.44 # it seems sane; you treat short reads as outright failures now so there's no parsing indeterminate buffers for data that may or may not be sane 22.45.01 # <_bilgus> it adds 4 to it though 22.46.51 # you mean before the calls to read_score_track_contents() ? 22.47.26 # I'd think you should be calling that with datasize, not valsize. 22.47.47 # since valsize includes the "header" that's already been read 22.48.27 # <_bilgus> uh it gets datasz just above 22.48.48 # <_bilgus> i think value sz would be for the individual field think bstrs 22.49.37 # ok 22.49.53 # <_bilgus> L: 357 might be an error 22.50.17 # why? I'd think a short read here would be bad? 22.50.44 # <_bilgus> it looks like it only checks tmp[3] 22.50.50 # <_bilgus> ot up to 22.50.54 # <_bilgus> or* 22.51.07 # <_bilgus> oh that would be 4 22.51.08 # tmp[0]->tmp[3] 22.51.10 # <_bilgus> duh 22.51.10 # yeah 22.54.35 # <_bilgus> I was begining to think contets was some audio data format I was unaware of 22.56.06 # looks like we've been hit by a few more bots about a week ago. 3x typical daily bandwidth.. 22.57.23 # <_bilgus> too bad we can't send them to ads 22.57.30 # <_bilgus> get paid for it 22.58.23 # Build Server message: 3New build round started. Revision 603e749c1d, 303 builds, 9 clients. 23.00.27 # <_bilgus> braewoods I left a comment on your inflate lib 23.00.40 # and I replied to it 23.01.09 # <_bilgus> where? 23.01.31 # It didn't save it? 23.02.05 # <_bilgus> will it be good w/ unsigned? 23.02.37 # _bilgus: yes. i was planning to deal with that in the callbacks, folding errors to 0. 23.03.03 # "Yes but I was planning to have the caller return 0 if this occurs to signal end of input. My code doesn't care WHY it can't provide more data. The caller knows and can store that if they care." 23.03.11 # <_bilgus> ok i'll submit it 23.04.05 # <_bilgus> my build should be around half way through yours is queued 23.08.32 # Build Server message: 3Build round completed after 609 seconds. 23.08.36 # Build Server message: 3Revision 603e749c1d result: All green 23.08.42 # Build Server message: 3New build round started. Revision 60933d98c6, 303 builds, 9 clients. 23.10.00 # <_bilgus> be back in a while 23.18.13 # Build Server message: 3Build round completed after 572 seconds. 23.18.15 # Build Server message: 3Revision 60933d98c6 result: All green 23.32.36 Quit pablocastellanos (Ping timeout: 272 seconds) 23.49.15 Quit dconrad (Remote host closed the connection)