| 00:48:02 | | Quit othello7 (Ping timeout: 256 seconds) |
| 00:48:44 | | Join _bilgus_ [0] (~bilgus@syn-162-154-213-134.res.spectrum.com) |
| 00:50:42 | | Quit _bilgus__ (Ping timeout: 255 seconds) |
| 01:00 |
| 01:09:46 | _bilgus_ | g#5771 this one looks pretty juicy as far as bugs go |
| 01:09:49 | rb-bluebot | Gerrit review #5771 at https://gerrit.rockbox.org/r/c/rockbox/+/5771 : [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:00 |
| 02:59:39 | | Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) |
| 03:00 |
| 03:03:01 | | Quit advcomp2019_ (Ping timeout: 255 seconds) |
| 03:19:13 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:19:14 | *** | No seen item changed, no save performed. |
| 05:49:25 | | Quit PheralSparky (Quit: Leaving) |
| 06:00 |
| 06:31:55 | | Quit CH23[m] (Read error: Connection reset by peer) |
| 06:32:46 | | Join CH23[m] [0] (~CH23@revspace/participant/ch23) |
| 07:00 |
| 07:19:17 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 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:00 |
| 09:19:20 | *** | Saving seen data "./dancer.seen" |
| 09:22:24 | speachy | so it's a 2 byte value that starts at offset 1, not 0? |
| 09:25:09 | speachy | currently 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:59 | speachy | 2nd pass: 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 29, 22, 24, 25, 27, 29, [31,] 0 |
| 09:29:30 | speachy | no wait, restarts at 1 each time. |
| 09:32:49 | speachy | offset 1-10 are 1st 5 chars, 14-25 are 6 more, 28-30 are two more. |
| 09:34:14 | speachy | So it should be: 1, 3, 5, 7, 9, 14, 16, 18, 20, 22, 24, 28, 30. |
| 09:35:03 | speachy | OTOH what we have _clearly_ displays filenames correctly, so... |
| 09:36:42 | speachy | seems to me that '-=1' should be '+=3' to match the comment? |
| 09:38:43 | speachy | (and with that, the sequence will hit 30..32, which will result in the original (i< 32) check being correct. |
| 09:39:25 | speachy | this code has been here since 7d1a47cf137 in 2013. |
| 09:43:19 | speachy | (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:30 | speachy | I 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:25 | speachy | I don't understand how this works at all. |
| 09:49:31 | _bilgus_ | IKR! |
| 09:49:38 | speachy | how 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:12 | speachy | This is the "correct" ordering accoring to the LFN spec: 1, 3, 5, 7, 9, 14, 16, 18, 20, 22, 24, 28, 30 |
| 09:53:59 | speachy | data[0] is a sequence number, not part of the filename. unless you're asking about somethig else? |
| 09:54:24 | speachy | the 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:18 | speachy | https://github.com/torvalds/linux/blob/master/include/uapi/linux/msdos_fs.h |
| 09:56:26 | speachy | the last two structs in that list. |
| 09:56:57 | speachy | they are two overlays on the same 32-byte block of data. |
| 09:58:40 | _bilgus_ | same as what I just typed yes |
| 09:59:03 | speachy | LFN uses a standard "direntry" for the shortname, size, start cluster, etc. and between 1 and 20 LFN entries. |
| 09:59:45 | speachy | the 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 |
| 10:00:32 | speachy | and I'm still scratching my head how the code as written works at all... |
| 10:01:48 | speachy | because 25 it results in a sequence of 24,25,27,29,31,0 instead of 24,28,30,0 |
| 10:04:09 | speachy | oh oh oh. there are no BREAKs in this case statement. |
| 10:04:22 | speachy | so -1 + 3 = +2. |
| 10:04:32 | _bilgus_ | ahhh |
| 10:04:59 | speachy | that means it'll never return i>30 |
| 10:05:04 | speachy | and 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:28 | speachy | if i = 30 going in , then i = 32 at the end of the case statement, meaning (i < 32 ? i : 0) return 0. |
| 10:08:05 | speachy | unless 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:05 | speachy | exactly |
| 10:10:41 | speachy | ....this sounds like a false positive. |
| 10:11:30 | speachy | I 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:05 | speachy | if 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:14:28 | _bilgus_ | throwing* |
| 10:16:36 | speachy | so, 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:04 | speachy | well presumably if you get to the last screen, you still want to finish reading it before it quits. |
| 10:19:48 | _bilgus_ | true |
| 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:22 | speachy | yeah, I Was wondering if there might be a justification for adding multi-file support to the text viewer |
| 10:21:35 | speachy | I mean, it's just code and feature creep. :D |
| 10:21:55 | _bilgus_ | in a plugin so great place for it |
| 10:22:12 | _bilgus_ | :) |
| 10:22:18 | speachy | hmm, did the textviewer plugin ever get basic voice support for its menus etc? |
| 10:23:33 | speachy | no it did not. |
| 10:24:10 | speachy | we 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:27 | speachy | in our release notes: "having solved all other problems, the text viewer now supports multiple files!" |
| 10:25:34 | _bilgus_ | lol |
| 10:26:06 | speachy | should we ever get that release out, ugh. |
| 10:26:16 | speachy | oh that reminds me. |
| 10:26:48 | speachy | https://moonlit.market/products/imcort-sd-card-adapter-for-the-ipod-classic-classic-connect |
| 10:27:06 | speachy | A completely different design of ATA<->SD adapter. |
| 10:27:17 | speachy | I'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:06 | _bilgus_ | hmm |
| 10:28:37 | gevaerts | _bilgus_: I do have a gigabeast that has been in towers, yes :) |
| 10:28:45 | speachy | commodity SD cards are about as trustworthy as disposable USB keyfobs. |
| 10:28:54 | gevaerts | (*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:14 | _bilgus_ | https://gerrit.rockbox.org/r/c/rockbox/+/5764 |
| 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:20 | Ctcp | Ignored 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:47 | speachy | either 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:25 | gevaerts | Well, good news so far, it switches on if I plug it into power |
| 10:42:05 | gevaerts | I 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:54 | gevaerts | (it's running a build from 2009 apparently... r21692M-090706) |
| 10:47:00 | speachy | I'm pretty sure we confirmed that the gigabeast will boot with the gcc49 builds. |
| 10:47:55 | gevaerts | I'm trying to remember where the toolchains are on my laptop so I can check which ones I have... |
| 10:48:05 | gevaerts | (I really *am* inactive!) |
| 10:49:18 | gevaerts | Is that arm-elf-eabi-gcc-4.9.4? |
| 10:50:40 | gevaerts | Also, 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:17 | speachy | yeah |
| 10:51:43 | speachy | just main. If you're feeling brave the new bootloader builds could use testing too. :D |
| 10:53:00 | gevaerts | I'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:14 | speachy | that's entirely up to you. :) |
| 10:54:51 | speachy | my box of rockbox boxes still has room in it |
| 10:56:39 | gevaerts | I have a non-patched build running now, so I should be fine |
| 10:56:52 | gevaerts | I'll test that first to make sure |
| 11:00 |
| 11:02:23 | _bilgus_ | gevaerts, https://www.mediafire.com/file/sjfs7gowg4b05za/rockbox-GigabeatS-f0b3605b81.zip/file |
| 11:03:18 | speachy | (the gigabeast has daily and dev builds on the download site fwiw) |
| 11:03:34 | speachy | oh d'oh nevermind brain fart |
| 11:06:21 | gevaerts | Ok, it boots with that |
| 11:06:34 | gevaerts | I 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:22 | gevaerts | I'll find some audio to put on it |
| 11:07:34 | speachy | run the diskbench plugin? |
| 11:07:43 | speachy | that ought to pound things |
| 11:07:46 | _bilgus_ | yeah that would be a good idea too |
| 11:10:23 | gevaerts | Hmmm |
| 11:11:01 | gevaerts | I'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:11 | gevaerts | Once 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:42 | gevaerts | I'll do that later |
| 11:24:32 | gevaerts | The 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] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 11:43:45 | gevaerts | Ok, my 7 GB files match, and the USB screen oddness also happens with daily |
| 12:00 |
| 12:30:37 | | Join othello8 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 12:32:48 | gevaerts | test_disk from my own build is also happy |
| 12:36:51 | | Join lebellium [0] (~lebellium@2a01cb0405d07f002421ea41f7c66b8f.ipv6.abo.wanadoo.fr) |
| 12:50:58 | | Quit __builtin (Read error: Connection reset by peer) |
| 12:51:03 | | Join _builtin [0] (~quassel@rockbox/developer/builtin) |
| 13:00 |
| 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:00 |
| 15:15:17 | | Quit IPG (Ping timeout: 268 seconds) |
| 15:19:29 | *** | Saving seen data "./dancer.seen" |
| 16:00 |
| 16:05:54 | | Quit davisr (Quit: yeehaw) |
| 17:00 |
| 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:00 |
| 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 |
| 19:00:17 | rb-bluebot | Build Server message: New build round started. Revision 74552d5404, 304 builds, 9 clients. |
| 19:00:18 | rb-bluebot | [coverity] RFC ata-imx31.c UDMA mode timing tables out of bounds reads by William Wilgus |
| 19:07:50 | rb-bluebot | Build Server message: Build round completed after 453 seconds. |
| 19:07:51 | rb-bluebot | Build Server message: Revision 74552d5404 result: All green |
| 19:12:00 | | Join jjs0077018310196 [0] (jjs007@gateway/vpn/protonvpn/jjs007) |
| 19:13:49 | rb-bluebot | Build Server message: New build round started. Revision e54dedd8df, 304 builds, 9 clients. |
| 19:13:49 | rb-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:05 | rb-bluebot | Build Server message: Build round completed after 495 seconds. |
| 19:22:06 | rb-bluebot | Build Server message: Revision e54dedd8df result: All green |
| 19:22:09 | rb-bluebot | Build Server message: New build round started. Revision c96d728d81, 304 builds, 9 clients. |
| 19:22:10 | rb-bluebot | [coverity] debug-imx233.c dbg_hw_info_audio() use strlcat, fix snprintf call by William Wilgus |
| 19:29:45 | rb-bluebot | Build Server message: Build round completed after 456 seconds. |
| 19:29:46 | rb-bluebot | Build Server message: Revision c96d728d81 result: 0 errors 9 warnings |
| 19:31:52 | _bilgus_ | bah |
| 20:00 |
| 20:04:58 | rb-bluebot | Build Server message: New build round started. Revision c6473f4e7f, 304 builds, 9 clients. |
| 20:04:59 | rb-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:21 | rb-bluebot | Build Server message: Build round completed after 503 seconds. |
| 20:13:22 | rb-bluebot | Build Server message: Revision c6473f4e7f result: All green |
| 20:13:50 | _bilgus_ | that usually means I screwed something up |
| 21:00 |
| 21:19:39 | *** | No seen item changed, no save performed. |
| 22:00 |
| 22:57:34 | | Quit cockroach (Quit: leaving) |
| 23:00 |
| 23:19:41 | *** | Saving seen data "./dancer.seen" |
| 23:39:15 | | Quit massiveH (Quit: Leaving) |
| 23:43:26 | rb-bluebot | Build Server message: New build round started. Revision f9b15d951c, 304 builds, 9 clients. |
| 23:43:26 | rb-bluebot | [coverity] folder_select.c find_from_filename() guard against NULL by William Wilgus |
| 23:50:54 | rb-bluebot | Build Server message: Build round completed after 448 seconds. |
| 23:50:55 | rb-bluebot | Build Server message: Revision f9b15d951c result: All green |
icon identifies that the person is a core developer (has commit access).