Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2021-08-06

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] (
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] (
08:40:49***No seen item changed, no save performed.
09:00:34 Quit massiveH (Quit: Leaving)
09:08:45speachywtf is that (MAX_LOGF_SIZE-1) doing in there?
09:13:35_bilgusmaybe the log is backwards?
09:14:19_bilgusthat would push the pointer to the end of the buffer but seems wrong..
09:14:43speachyas in, what does that actually do? it evaluates as a cast
09:14:54speachy(MAX_LOGF_SIZE-i) &logfbuffer[i + 1]
09:15:19speachyie (16383) &logfbuffer[i+1]
09:15:26speachyin a format string
09:15:32gevaertsI'm a bit confused too
09:16:32_bilgusOH is it supposed to be the size specifier?
09:16:41speachyI 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:53speachythere is no size specifier to lcd_putsf()
09:17:22speachy(I've been trying to make sense of the pair of read-beyond-array-end issues in this code
09:17:26_bilgusmust be in a usually dead codepath?
09:17:50speachyno, logf_panic_dump() −− which I know I've personally triggered many times :)
09:17:52_bilgusyeah, #ifdef ROCKBOX_HAS_LOGDISKF
09:18:25speachyno, it's not in the LOGDISKF section
09:18:25gevaertsI don't like what git blame says about who committed that
09:20:57_bilgusyeah its in the !pctool part WEiRD
09:20:57speachyThere'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_bilgusI guess its a read so itd just be garbled data
09:22:03speachypotentially a lot since we can't depend on null termination
09:22:24_bilgusmaybe next build o coverity needs logf
09:23:21speachythis issue it found is legit though
09:23:29gevaertsAt this point the only thing that means to me is a bitwise and, but that makes no sense...
09:24:33gevaertsI don't do enough C these days...
09:24:38speachybasically 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:01speachy(the overflow, not the wtf construct)
09:26:33speachymake 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:22speachymaybe I'm being particularly dense today but it seems logf_panic_dump() is simply broken when it comes to wrapped buffers
09:35:06gevaertsIt's not the most commonly run code
09:35:20gevaertsSo that wouldn't actually surprise me at all
09:36:00speachywe should run the if(logwrap) section first to dump the oldest stuff, _then_ then dump from the start of the buffer.
09:43:06speachytbh this whole thing seems a lot more complicated than it needs to be.
09:43:17speachypanic_dump just needs to blindly dump out the logf buffer.
09:45:41speachyif (wrapped) { dump(logfindex); } dump(logf_buffer);
09:46:23speachylogfindex-1 is the \0 terminator, and is guaranteed to be there if anything has been written to the buffer.
09:48:31speachyjust need to ensure logfbuffer[size+1] is also \0
09:50:33speachyaaah, now I get it; ok, it's a line-by-line dump intentionally.
09:52:19speachyso the "fix" seems to consist of just bumping the buffer by 1 and making sure that padding is null-terminated.
09:59:30speachyI'd appreciate a look at g#3661 please
09:59:32rb-bluebotGerrit review #3661 at : logf: Fix multiple issues with logf_panic_dump() by Solomon Peachy
10:00:00speachyhopefully I didn't make things worse
10:03:13 Join cockroach [0] (~blattodea@user/cockroach)
10:03:32gevaerts"highly questionable" is a nice euphemism there :)
10:04:41speachylogf_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:30speachy... wait. that's why it's backwards. bad peachy
10:05:51speachyI'll fix that
10:08:38speachyok, updated.
10:08:56gevaertsSee, 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 -
11:01:38rb-bluebotBuild Server message: New build round started. Revision 835d0c737a, 303 builds, 10 clients.
11:01:45 Join rogeliodh [0] (
11:13:12rb-bluebotBuild Server message: Build round completed after 694 seconds.
11:13:14rb-bluebotBuild Server message: Revision 835d0c737a result: All green
11:38:26 Join amachronic [0] (~amachroni@user/amachronic)
11:47:22rb-bluebotBuild Server message: New build round started. Revision 34fcea0b20, 303 builds, 10 clients.
11:56:40rb-bluebotBuild Server message: Build round completed after 558 seconds.
11:56:42rb-bluebotBuild Server message: Revision 34fcea0b20 result: All green
12:10:43rb-bluebotBuild Server message: New build round started. Revision 6b1b7b6016, 303 builds, 10 clients.
12:20:52rb-bluebotBuild Server message: Build round completed after 609 seconds.
12:20:55rb-bluebotBuild Server message: Revision 6b1b7b6016 result: All green
12:40:54***Saving seen data "./dancer.seen"
14:22:55rb-bluebotBuild Server message: New build round started. Revision b8b195a296, 303 builds, 10 clients.
14:32:19rb-bluebotBuild Server message: Build round completed after 564 seconds.
14:32:21rb-bluebotBuild Server message: Revision b8b195a296 result: All green
14:32:24rb-bluebotBuild Server message: New build round started. Revision 1a9a5fc279, 303 builds, 10 clients.
14:40:58***No seen item changed, no save performed.
14:41:59rb-bluebotBuild Server message: Build round completed after 575 seconds.
14:42:02rb-bluebotBuild Server message: Revision 1a9a5fc279 result: All green
14:42:04rb-bluebotBuild Server message: New build round started. Revision d541a72a0e, 303 builds, 10 clients.
14:51:01rb-bluebotBuild Server message: Build round completed after 537 seconds.
14:51:04rb-bluebotBuild Server message: Revision d541a72a0e result: 0 errors 75 warnings
14:51:06rb-bluebotBuild Server message: New build round started. Revision 02b940396b, 303 builds, 10 clients.
15:00:33rb-bluebotBuild Server message: Build round completed after 568 seconds.
15:00:35rb-bluebotBuild Server message: Revision 02b940396b result: 0 errors 75 warnings
15:00:38rb-bluebotBuild Server message: New build round started. Revision 257ba1d2e0, 303 builds, 10 clients.
15:10:02rb-bluebotBuild Server message: Build round completed after 565 seconds.
15:10:05rb-bluebotBuild Server message: Revision 257ba1d2e0 result: 0 errors 75 warnings
15:10:08rb-bluebotBuild Server message: New build round started. Revision 2008b7d1b0, 303 builds, 10 clients.
15:19:28rb-bluebotBuild Server message: Build round completed after 560 seconds.
15:19:30rb-bluebotBuild Server message: Revision 2008b7d1b0 result: All green
15:51:42 Quit amachronic (Ping timeout: 276 seconds)
16:15:11 Join bilgus_ph [0] (~bilgus_ph@
16:17:14bilgus_phI 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:50bilgus_phLike 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:22bilgus_phInit variables *vars*
16:19:57 Quit bilgus_ph (Client Quit)
16:41:00***Saving seen data "./dancer.seen"
17:18:09 Join Bobathan [0] (
17:24:50speachyno wait, wrong one.
17:25:11speachy(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@
20:04:49 Quit Bobathan (Quit: ZNC 1.7.2+deb3 -
20:06:46 Join dconrad [0] (~dconrad@
20:20:12 Join massiveH [0] (
20:41:04***Saving seen data "./dancer.seen"
20:44:42dconrad32-bit SW Vol: it kinda works this time! g#3669
20:44:44rb-bluebotGerrit review #3669 at : Higher-bit SW Vol, take three by Dana Conrad
20:44:59dconradit's, uh, got a couple issues tho haha
20:45:09dconradplays audio tho
21:06:02rb-bluebotBuild Server message: New build round started. Revision 8a8fd3d4a3, 303 builds, 9 clients.
21:07:15speachyscale_buffer_trans clips to 16 bit
21:08:14dconradah, I'll try just commenting out the clip_sample_16()
21:11:05dconradyup, good catch
21:17:00rb-bluebotBuild Server message: Build round completed after 658 seconds.
21:17:06rb-bluebotBuild Server message: Revision 8a8fd3d4a3 result: All green
21:41:32 Quit massiveH (Quit: Leaving)
21:47:15dconradoh, I guess in pcm_sync_pcm_factors() the pcm_scaling_fn should be hardcoded to pcm_scale_buffer_cut
21:47:18dconradmakes sense
22:02:23 Quit cockroach (Quit: leaving)
22:13:41 Join massiveH [0] (
22:23:18speachyok, made the mailing list and forum announcement about the downtime.
22:24:14 Join Moriar [0] (
22:39:20_bilgusspeachy got a moment to look at something for sanity?
22:40:44_bilgus g#3671
22:40:46rb-bluebotGerrit review #3671 at : metadata/smaf.c hand;e read errors by William Wilgus
22:41:08***Saving seen data "./dancer.seen"
22:42:15braewoods_bilgus: s/;/l/
22:42:30_bilgusyeah I saw that
22:42:57_bilguskinda inbetween drywall sheets and hoped someone else could look i'm testing it atm
22:44:44speachyit 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_bilgusit adds 4 to it though
22:46:51speachyyou mean before the calls to read_score_track_contents() ?
22:47:26speachyI'd think you should be calling that with datasize, not valsize.
22:47:47speachysince valsize includes the "header" that's already been read
22:48:27_bilgusuh it gets datasz just above
22:48:48_bilgusi think value sz would be for the individual field think bstrs
22:49:53_bilgusL: 357 might be an error
22:50:17speachywhy? I'd think a short read here would be bad?
22:50:44_bilgusit looks like it only checks tmp[3]
22:50:50_bilgusot up to
22:51:07_bilgusoh that would be 4
22:54:35_bilgusI was begining to think contets was some audio data format I was unaware of
22:56:06speachylooks like we've been hit by a few more bots about a week ago. 3x typical daily bandwidth..
22:57:23_bilgustoo bad we can't send them to ads
22:57:30_bilgusget paid for it
22:58:23rb-bluebotBuild Server message: New build round started. Revision 603e749c1d, 303 builds, 9 clients.
23:00:27_bilgusbraewoods I left a comment on your inflate lib
23:00:40braewoodsand I replied to it
23:01:31braewoodsIt didn't save it?
23:02:05_bilguswill it be good w/ unsigned?
23:02:37braewoods_bilgus: yes. i was planning to deal with that in the callbacks, folding errors to 0.
23:03:03braewoods"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_bilgusok i'll submit it
23:04:05_bilgusmy build should be around half way through yours is queued
23:08:32rb-bluebotBuild Server message: Build round completed after 609 seconds.
23:08:36rb-bluebotBuild Server message: Revision 603e749c1d result: All green
23:08:42rb-bluebotBuild Server message: New build round started. Revision 60933d98c6, 303 builds, 9 clients.
23:10:00_bilgusbe back in a while
23:18:13rb-bluebotBuild Server message: Build round completed after 572 seconds.
23:18:15rb-bluebotBuild Server message: Revision 60933d98c6 result: All green
23:32:36 Quit pablocastellanos (Ping timeout: 272 seconds)
23:49:15 Quit dconrad (Remote host closed the connection)

Previous day | Next day