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 2024-06-05

00:48:02 Quit othello7 (Ping timeout: 256 seconds)
00:48:44 Join _bilgus_ [0] (
00:50:42 Quit _bilgus__ (Ping timeout: 255 seconds)
01:09:46_bilgus_ g#5771 this one looks pretty juicy as far as bugs go
01:09:49rb-bluebotGerrit review #5771 at : [coverity] fat.c fatlong_parse_entry() buffer overrun, fix warning basisname by William Wilgus
01:11:48_bilgus_so longent_char_first returns 1, longent_char_next adds 2 and has some screwy stuff at 11-26 and continues at 25..
01:12:51_bilgus_the loop then stops at i < 32 but 31 + 1 == 32 and reading off the end
01:19:10***Saving seen data "./dancer.seen"
01:20:03_bilgus_just had a thought about the way it starts at 1 and stops at 0 maybe it is meant to read the first element of the next entry??
01:47:10 Quit braewoods_ (Read error: Connection reset by peer)
01:47:19 Join braewoods__ [0] (~braewoods@user/braewoods)
02:59:39 Join advcomp2019__ [0] (~advcomp20@user/advcomp2019)
03:03:01 Quit advcomp2019_ (Ping timeout: 255 seconds)
03:19:13***Saving seen data "./dancer.seen"
05:19:14***No seen item changed, no save performed.
05:49:25 Quit PheralSparky (Quit: Leaving)
06:31:55 Quit CH23[m] (Read error: Connection reset by peer)
06:32:46 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
07:19:17***Saving seen data "./dancer.seen"
08:28:34 Join braewoods [0] (~braewoods@user/braewoods)
08:28:36 Quit braewoods__ (Remote host closed the connection)
08:54:59 Join __builtin [0] (~quassel@rockbox/developer/builtin)
09:19:20***Saving seen data "./dancer.seen"
09:22:24speachyso it's a 2 byte value that starts at offset 1, not 0?
09:25:09speachycurrently it returns: 1 -> 3, 5, 7, 9, 14, 16, 18, 20, 22, 24, 25, 27, 29, 31, 0 You changed that to end at 29, 0
09:25:59speachy2nd pass: 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 29, 22, 24, 25, 27, 29, [31,] 0
09:29:30speachyno wait, restarts at 1 each time.
09:32:49speachyoffset 1-10 are 1st 5 chars, 14-25 are 6 more, 28-30 are two more.
09:34:14speachySo it should be: 1, 3, 5, 7, 9, 14, 16, 18, 20, 22, 24, 28, 30.
09:35:03speachyOTOH what we have _clearly_ displays filenames correctly, so...
09:36:42speachyseems to me that '-=1' should be '+=3' to match the comment?
09:38:43speachy(and with that, the sequence will hit 30..32, which will result in the original (i< 32) check being correct.
09:39:25speachythis code has been here since 7d1a47cf137 in 2013.
09:43:19speachy(Sorry, +=2, not +=3)
09:47:08_bilgus_pulling apart the spec for the 32 bit value in FAT offset 14 thru 25 are created / modified times
09:47:29_bilgus_those are getting flipped to do endian conversion
09:47:30speachyI don't get that 26->25 backwards jump when it should be +2 instead
09:48:51_bilgus_that said it still works right making it stop at 30
09:49:25speachyI don't understand how this works at all.
09:49:38speachyhow it's _ever_ worked correctly
09:50:40_bilgus_I think I have 75% of it worked out and I did verify element 31 is returned in the loop which is what coverity was bitching about
09:51:51_bilgus_rightfully apparently but the area around that roll over back to zero I'm not seeing how you get the first bit (data[0])
09:52:18_bilgus_unless its shifted by 1 bit or something
09:53:12speachyThis is the "correct" ordering accoring to the LFN spec: 1, 3, 5, 7, 9, 14, 16, 18, 20, 22, 24, 28, 30
09:53:59speachydata[0] is a sequence number, not part of the filename. unless you're asking about somethig else?
09:54:24speachythe return value of 0 is used as a "restart on the next block" flag.
09:54:24_bilgus_i'm saying in the raw data entry we are stepping thru
09:54:46_bilgus_element 0-7 is shortname
09:55:12_bilgus_8-10 is ext 3 chars
09:56:13_bilgus_11 is attrib 12 user atr 13 data 1 byte 14-15 is HMS 2 bytes
09:56:26speachythe last two structs in that list.
09:56:57speachythey are two overlays on the same 32-byte block of data.
09:58:40_bilgus_same as what I just typed yes
09:59:03speachyLFN uses a standard "direntry" for the shortname, size, start cluster, etc. and between 1 and 20 LFN entries.
09:59:45speachythe code that coverity flagged isn't the shortname manipulation, it's the LFN manipulation. so I'm not sure why the shortname stuff matters in this context.
10:00:32speachyand I'm still scratching my head how the code as written works at all...
10:01:48speachybecause 25 it results in a sequence of 24,25,27,29,31,0 instead of 24,28,30,0
10:04:09speachyoh oh oh. there are no BREAKs in this case statement.
10:04:22speachyso -1 + 3 = +2.
10:04:59speachythat means it'll never return i>30
10:05:04speachyand that test is ok.
10:05:25_bilgus_oh yes it will
10:05:39_bilgus_put a panic in there and boot it
10:07:28speachyif i = 30 going in , then i = 32 at the end of the case statement, meaning (i < 32 ? i : 0) return 0.
10:08:05speachyunless i = 29 going in, which is a bug in the caller.
10:09:56_bilgus_ah ok so its even now so its 28 30 then it rolls to zero
10:10:41speachy....this sounds like a false positive.
10:11:30speachyI suppose i < 31 is "correct" strictly speaking but sheesh.
10:11:36_bilgus_I think you are right and changing the bounds didn't change anything because it was still a proper sequence
10:13:05speachyif you decide to commit this you need to fix the "return 25" back to "return 28" and I'd add a comment saying this is an intentional fallthrough.
10:14:18_bilgus_I will, it was trowing me off like why would you flip the bytes but stop at the cluster
10:16:36speachyso, do you have an opinon on the slightly hack-y "legal notices" thing I added?
10:17:55_bilgus_I figured we can add a flag to the viewer plugin to make it auto close at the end or something
10:18:18_bilgus_otherwise it serves the purpose
10:19:04speachywell presumably if you get to the last screen, you still want to finish reading it before it quits.
10:20:27_bilgus_itd be nice if it just loaded both as you scrolled but eh its there how often do you read it
10:21:09_bilgus_if its more than once you might have issues
10:21:22speachyyeah, I Was wondering if there might be a justification for adding multi-file support to the text viewer
10:21:35speachyI mean, it's just code and feature creep. :D
10:21:55_bilgus_in a plugin so great place for it
10:22:18speachyhmm, did the textviewer plugin ever get basic voice support for its menus etc?
10:23:33speachyno it did not.
10:24:10speachywe can't do anything about voicing the text you're viewing but.. the menus at least (and the filename it's viewing) should be voiced if possible.
10:25:27speachyin our release notes: "having solved all other problems, the text viewer now supports multiple files!"
10:26:06speachyshould we ever get that release out, ugh.
10:26:16speachyoh that reminds me.
10:27:06speachyA completely different design of ATA<->SD adapter.
10:27:17speachyI'm very curious to see how these work.
10:27:21_bilgus_gevaerts, did you have a gigabeast in your tower of rockbox?
10:28:00_bilgus_'Please avoid using SanDisk cards'
10:28:37gevaerts_bilgus_: I do have a gigabeast that has been in towers, yes :)
10:28:45speachycommodity SD cards are about as trustworthy as disposable USB keyfobs.
10:28:54gevaerts(*no* idea if it still works. These things are finicky at the best of times...)
10:30:51_bilgus_I have a apparent UDMA timing bug
10:31:37_bilgus_its been working for 16 years but is terribly broken and I need someone to test this
10:32:34_bilgus_oh iguess MDMA too
10:34:20CtcpIgnored 5 channel CTCP requests in 16 hours and 31 minutes at the last flood
10:34:20*_bilgus_ fingers crossed
10:35:21_bilgus_speachy I think a lot of that might be big name gets more counterfeit
10:35:47speachyeither way, it's a crapshoot. even when obtained via nominally "good" channels.
10:36:13_bilgus_yeah the more you understand sd cards the more you make backups
10:41:25gevaertsWell, good news so far, it switches on if I plug it into power
10:42:05gevaertsI suspect you'll be annoying and want me to install a new build on it though, so I'll also need to find a mini usb cable :)
10:42:54gevaerts(it's running a build from 2009 apparently... r21692M-090706)
10:47:00speachyI'm pretty sure we confirmed that the gigabeast will boot with the gcc49 builds.
10:47:55gevaertsI'm trying to remember where the toolchains are on my laptop so I can check which ones I have...
10:48:05gevaerts(I really *am* inactive!)
10:49:18gevaertsIs that arm-elf-eabi-gcc-4.9.4?
10:50:40gevaertsAlso, is it just main or also bootloader? I don't remember much about the gigabeast bootloader apart from it being a pain to deal with, so I'm hoping just main
10:51:43speachyjust main. If you're feeling brave the new bootloader builds could use testing too. :D
10:53:00gevaertsI'm not too worried about making this thing not boot, it's sitting in a drawer not doing much. But at some point it's going to be more efficient to ask for someone's address and ship the thing :)
10:54:13_bilgus_I'll compile you a build so you don't have to go thru all that
10:54:14speachythat's entirely up to you. :)
10:54:51speachymy box of rockbox boxes still has room in it
10:56:39gevaertsI have a non-patched build running now, so I should be fine
10:56:52gevaertsI'll test that first to make sure
11:03:18speachy(the gigabeast has daily and dev builds on the download site fwiw)
11:03:34speachyoh d'oh nevermind brain fart
11:06:21gevaertsOk, it boots with that
11:06:34gevaertsI bet you want something more than that though :)
11:07:03_bilgus_awesome thats truly good enough but maybe play a few songs and skip around in the filesystem a bit?
11:07:22gevaertsI'll find some audio to put on it
11:07:34speachyrun the diskbench plugin?
11:07:43speachythat ought to pound things
11:07:46_bilgus_yeah that would be a good idea too
11:11:01gevaertsI'm still happily copying files, but the screen is showing the main menu... It's not responding though
11:17:16_bilgus_if it doesn't come out of it could you check the daily builds and see if it behaves differently?
11:19:11gevaertsOnce I unmount and unplug it seems back to normal
11:19:22***No seen item changed, no save performed.
11:22:11_bilgus_maybe check daily too anyway if you don't mind just to verify its not this patch causing the issue
11:22:19_bilgus_if you don't mind,
11:22:36_bilgus_and thank you igtg but ill check back
11:22:42gevaertsI'll do that later
11:24:32gevaertsThe build doesn't have the test plugins, so for now I'm just checking hashes of all the files I copied
11:33:34 Join davisr [0] (~davisr@fsf/emeritus/davisr)
11:40:12 Join othello7 [0] (
11:43:45gevaertsOk, my 7 GB files match, and the USB screen oddness also happens with daily
12:30:37 Join othello8 [0] (
12:32:48gevaertstest_disk from my own build is also happy
12:36:51 Join lebellium [0] (
12:50:58 Quit __builtin (Read error: Connection reset by peer)
12:51:03 Join _builtin [0] (~quassel@rockbox/developer/builtin)
13:06:21 Quit CH23[m] (Read error: Connection reset by peer)
13:06:43 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
13:10:57 Quit CH23[m] (Read error: Connection reset by peer)
13:11:10 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
13:13:12 Quit CH23[m] (Read error: Connection reset by peer)
13:14:04 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
13:19:25***Saving seen data "./dancer.seen"
13:19:39 Quit othello8 (Ping timeout: 268 seconds)
13:48:45 Quit CH23[m] (Ping timeout: 255 seconds)
13:49:54 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
13:55:12 Quit CH23[m] (Read error: Connection reset by peer)
13:55:28 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
15:15:17 Quit IPG (Ping timeout: 268 seconds)
15:19:29***Saving seen data "./dancer.seen"
16:05:54 Quit davisr (Quit: yeehaw)
17:06:31 Quit _builtin (Remote host closed the connection)
17:09:13 Quit sam_d (Quit: Bye)
17:10:50 Join sam_d [0] (~sam@user/sam-d/x-8933526)
17:19:33***Saving seen data "./dancer.seen"
18:03:35 Join cockroach [0] (~blattodea@user/cockroach)
18:08:34 Quit lebellium (Quit: Leaving)
18:53:31_bilgus_gevaerts, thank you
19:00:17rb-bluebotBuild Server message: New build round started. Revision 74552d5404, 304 builds, 9 clients.
19:00:18rb-bluebot[coverity] RFC ata-imx31.c UDMA mode timing tables out of bounds reads by William Wilgus
19:07:50rb-bluebotBuild Server message: Build round completed after 453 seconds.
19:07:51rb-bluebotBuild Server message: Revision 74552d5404 result: All green
19:12:00 Join jjs0077018310196 [0] (jjs007@gateway/vpn/protonvpn/jjs007)
19:13:49rb-bluebotBuild Server message: New build round started. Revision e54dedd8df, 304 builds, 9 clients.
19:13:49rb-bluebot[coverity] fat.c fatlong_parse_entry() buffer overrun, fix warning basisname by William Wilgus
19:19:36***Saving seen data "./dancer.seen"
19:21:00 Join massiveH [0] (~massiveH@2600:4040:a982:c800:bc72:d2b3:4ed1:74f4)
19:22:05rb-bluebotBuild Server message: Build round completed after 495 seconds.
19:22:06rb-bluebotBuild Server message: Revision e54dedd8df result: All green
19:22:09rb-bluebotBuild Server message: New build round started. Revision c96d728d81, 304 builds, 9 clients.
19:22:10rb-bluebot[coverity] debug-imx233.c dbg_hw_info_audio() use strlcat, fix snprintf call by William Wilgus
19:29:45rb-bluebotBuild Server message: Build round completed after 456 seconds.
19:29:46rb-bluebotBuild Server message: Revision c96d728d81 result: 0 errors 9 warnings
20:04:58rb-bluebotBuild Server message: New build round started. Revision c6473f4e7f, 304 builds, 9 clients.
20:04:59rb-bluebot[Fix Yellow] imx233_debug fix yellow by William Wilgus
20:11:58_bilgus_thats odd I didn't expect any code decreases by initializing to 0 you'd think itd add 80 or so bytes
20:13:21rb-bluebotBuild Server message: Build round completed after 503 seconds.
20:13:22rb-bluebotBuild Server message: Revision c6473f4e7f result: All green
20:13:50_bilgus_that usually means I screwed something up
21:19:39***No seen item changed, no save performed.
22:57:34 Quit cockroach (Quit: leaving)
23:19:41***Saving seen data "./dancer.seen"
23:39:15 Quit massiveH (Quit: Leaving)
23:43:26rb-bluebotBuild Server message: New build round started. Revision f9b15d951c, 304 builds, 9 clients.
23:43:26rb-bluebot[coverity] folder_select.c find_from_filename() guard against NULL by William Wilgus
23:50:54rb-bluebotBuild Server message: Build round completed after 448 seconds.
23:50:55rb-bluebotBuild Server message: Revision f9b15d951c result: All green

Previous day | Next day