| 00:00:52 | | Quit S|h|a|w|n (Remote host closed the connection) |
| 00:04:37 | | Join Stanley|00 [0] (~stanley00@unaffiliated/stanley00) |
| 00:07:10 | | Quit Stanley00 (Ping timeout: 260 seconds) |
| 00:20:01 | | Quit TheSeven (Disconnected by services) |
| 00:20:11 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 00:33:37 | _bilgus | everything |
| 01:00 |
| 01:09:57 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:10:00 | *** | No seen item changed, no save performed. |
| 04:00 |
| 04:15:43 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 04:46:16 | | Quit pamaury (Ping timeout: 256 seconds) |
| 04:48:27 | | Join petur [0] (~petur@199.59.5.11) |
| 04:48:27 | | Quit petur (Changing host) |
| 04:48:27 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 04:54:47 | | Quit Rondom (Remote host closed the connection) |
| 04:54:56 | | Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) |
| 05:00 |
| 05:09:13 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 05:10:03 | *** | Saving seen data "./dancer.seen" |
| 05:44:49 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 05:50:29 | edhelas | _bilgus that's a lot of things ! |
| 06:00 |
| 06:32:06 | | Quit Stanley|00 (Remote host closed the connection) |
| 07:00 |
| 07:10:05 | *** | Saving seen data "./dancer.seen" |
| 07:22:32 | | Join wodz_home [0] (~wodz@89-64-78-138.dynamic.chello.pl) |
| 07:26:05 | wodz_home | speachy: I have working prototype of bt support. Currently it is commandline which can initiate discovery (and filter results for a2dp_sink capability), pair and connect (using default agent), connect AudioSink. Then with help of parametrized asound.conf pcm entry I am able to aplay -D to bt headset. |
| 07:26:21 | speachy | wodz_home: oh, niiice. |
| 07:27:27 | speachy | when you do the aplay -D, can you include a −−dump-hw-params to see what the raw capabilities are? |
| 07:28:09 | speachy | (since they are presumably going to be different than the native pcm codec..) |
| 07:28:14 | wodz_home | The chalanges are: 1) It is based on gdbus. Agptek firmware provides this lib, no problem but rockbox building process will need to be tweaked. 2) No UI. 3) Not tested with our alsa pcm driver) |
| 07:28:22 | wodz_home | sure, wait a sec |
| 07:29:12 | speachy | bilgus is sorta working on a prototype UI, keeps getting distracted by our past sins. :) |
| 07:31:31 | wodz_home | HW Params of device "bluetooth:ADDRESS=80:C7:55:63:59:D6": |
| 07:31:31 | wodz_home | −−−−−−−−−−−−−−−−−−−− |
| 07:31:31 | wodz_home | ACCESS: MMAP_INTERLEAVED MMAP_NONINTERLEAVED MMAP_COMPLEX RW_INTERLEAVED RW_NONINTERLEAVED |
| 07:31:31 | DBUG | Enqueued KICK wodz_home |
| 07:31:31 | wodz_home | FORMAT: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE MU_LAW A_LAW IMA_ADPCM S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE |
| 07:31:31 | wodz_home | SUBFORMAT: STD |
| 07:31:33 | wodz_home | SAMPLE_BITS: [4 64] |
| 07:31:35 | wodz_home | FRAME_BITS: [4 640000] |
| 07:31:37 | wodz_home | CHANNELS: [1 10000] |
| 07:31:39 | wodz_home | RATE: [4000 4294967295) |
| 07:31:41 | wodz_home | PERIOD_TIME: (10666 256000] |
| 07:31:43 | wodz_home | PERIOD_SIZE: (42 1099511628) |
| 07:31:47 | wodz_home | PERIOD_BYTES: (21 4294967295) |
| 07:31:49 | wodz_home | PERIODS: (0 78536545) |
| 07:31:51 | wodz_home | BUFFER_TIME: [1 4294967295] |
| 07:31:53 | wodz_home | BUFFER_SIZE: [512 3298534882] |
| 07:31:55 | wodz_home | BUFFER_BYTES: [256 4294967295] |
| 07:31:57 | wodz_home | TICK_TIME: ALL |
| 07:31:59 | wodz_home | −−−−−−−−−−−−−−−−−−−− |
| 07:32:01 | wodz_home | ALSA lib audio/pcm_bluetooth.c:2056:(audioservice_recv) Too short (0 bytes) IPC packet from bluetoothd |
| 07:32:03 | wodz_home | aplay: set_params:1166: Unable to install hw params: |
| 07:32:05 | wodz_home | ACCESS: RW_INTERLEAVED |
| 07:32:07 | wodz_home | FORMAT: S16_LE |
| 07:32:09 | wodz_home | SUBFORMAT: STD |
| 07:32:11 | wodz_home | SAMPLE_BITS: 16 |
| 07:32:13 | wodz_home | FRAME_BITS: 32 |
| 07:32:17 | wodz_home | CHANNELS: 2 |
| 07:32:19 | wodz_home | RATE: 44100 |
| 07:32:21 | wodz_home | PERIOD_TIME: (46439 46440) |
| 07:32:23 | wodz_home | PERIOD_SIZE: 2048 |
| 07:32:25 | wodz_home | PERIOD_BYTES: 8192 |
| 07:32:27 | wodz_home | PERIODS: 3 |
| 07:32:29 | wodz_home | BUFFER_TIME: (139319 139320) |
| 07:32:31 | wodz_home | BUFFER_SIZE: 6144 |
| 07:32:33 | wodz_home | BUFFER_BYTES: 24576 |
| 07:32:35 | wodz_home | TICK_TIME: 0 |
| 07:33:01 | wodz_home | speachy: ^ |
| 07:33:04 | speachy | so in other words, the alsa bluetooth lib will translate from anything to whatever the hw needs. |
| 07:33:14 | wodz_home | seems so |
| 07:33:25 | speachy | but it's probably best to lock it to 44 &| 48 KHz. |
| 07:36:09 | speachy | wodz_home: our pcm alsa driver should allow the device to be changed at runtime now. There's no real provision for hw caps feedback still. |
| 07:37:42 | wodz_home | but do we need this considering bluetooth alsa device can ingest anything? |
| 07:40:22 | speachy | more of a cpu optimization. no sense in rendering at 192KHz with full DSP if it's going to get thrown out |
| 07:40:52 | speachy | and on that note, time to see the dentist. |
| 07:40:56 | wodz_home | ahh, I am not used to hires files |
| 08:00 |
| 08:30:31 | | Quit prof_wolfff (Ping timeout: 256 seconds) |
| 08:33:06 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 08:37:53 | | Quit Stanley00 (Ping timeout: 260 seconds) |
| 08:38:52 | | Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:dd7d:4237:a88a:8a76) |
| 08:39:23 | | Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) |
| 08:49:19 | | Quit kugel (Ping timeout: 265 seconds) |
| 09:00 |
| 09:10:06 | *** | Saving seen data "./dancer.seen" |
| 09:41:07 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:49:47 | | Join kugel [0] (~kugel@ip5b41481c.dynamic.kabel-deutschland.de) |
| 09:49:47 | | Quit kugel (Changing host) |
| 09:49:47 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 10:00 |
| 10:05:46 | | Quit akaWolf (Read error: Connection reset by peer) |
| 10:06:10 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 10:34:00 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 10:38:09 | speachy | braewoods: I've fixed one of the other traps, but the pile in the skinning code concerns me. On the arm side we're not triggering the same trap-ish asm behavior, which makes me suspect there's a deeper root cause we need to find/fix. |
| 10:38:34 | | Quit Stanley00 (Ping timeout: 256 seconds) |
| 10:39:04 | braewoods | speachy: perhaps. |
| 10:39:34 | speachy | (ie the theme/skin/whatever pointers can't legitimately be null, or badness will happen) |
| 10:41:19 | speachy | this might be releated to the theme reload segfault that bilgus ran into on the rocker |
| 10:41:57 | braewoods | maybe the m68k code gen notices these more |
| 10:42:06 | braewoods | since it seems to trigger TRAPs for those |
| 10:42:30 | braewoods | trap #7 specifically |
| 10:42:45 | braewoods | but we don't use traps so it needs to be disabled in some cases where this is legit behavior |
| 10:43:07 | braewoods | but those are few |
| 10:43:22 | braewoods | mostly stuff that needs direct HW access |
| 10:43:47 | braewoods | speachy: https://gerrit.rockbox.org/r/#/c/rockbox/+/2917/ <−− i removed the extra whitespace in this patch |
| 10:44:37 | braewoods | i'll look for more traps later but i was just investigating whether the bootloaders might have the same problem |
| 10:44:39 | braewoods | they don't. |
| 10:44:58 | braewoods | they're low level stuff so i thought it should be investigated |
| 10:44:58 | speachy | aha! found a 'udf' in the nano2g disasm, same place. |
| 10:45:06 | braewoods | udf? |
| 10:45:14 | speachy | the other targets I was looking at were 1/2bit screens |
| 10:45:20 | speachy | 'undefined' instruction |
| 10:45:29 | speachy | so it's not m68k-specific. |
| 10:45:34 | speachy | ok, gonna try an experiment. |
| 10:46:19 | braewoods | iirc, the LK's issue with this GCC additions was code like |
| 10:46:20 | speachy | backing off before the viewport rework, and see if it still generates the trap/udf |
| 10:46:35 | braewoods | (const struct ...* foo) |
| 10:46:42 | braewoods | size_t x = foo->size; |
| 10:46:48 | braewoods | if(foo == NULL) { ... } |
| 10:46:51 | braewoods | it would omit the if |
| 10:46:59 | braewoods | assumes foo cannot be null |
| 10:47:12 | speachy | yeah. |
| 10:47:14 | braewoods | checking after a dereference |
| 10:47:29 | | Quit pamaury (Quit: Konversation terminated!) |
| 10:48:04 | speachy | yeah, it's there prior to the viewport rejigger. |
| 10:48:05 | braewoods | if you're doing embedded, it doesn't matter so much, but in userspace C, it's illogical to do that. |
| 10:48:56 | speachy | so the odds are good that this has been a problem for all mips and hosted arm for a while now. |
| 10:49:20 | braewoods | and coldfire was just the first to expose it in an obvious instruction? |
| 10:49:55 | speachy | well, you tripped over it in the flash tool (which is a rare legitimate use for null pointer dereferences) |
| 10:52:56 | speachy | the stuff you found in the skin code is clearly due to bugs. |
| 10:53:19 | speachy | the trick is unwinding the tortuous path the gcc optimizer used to make that determination |
| 10:55:20 | fs-bluebot_ | Build Server message: New build round started. Revision 61f6987, 293 builds, 9 clients. |
| 10:57:18 | speachy | a bunch of plugins have 'trap #15' in 'em |
| 10:58:36 | braewoods | i'm going to look through gcc source code. what does it use traps for? |
| 10:59:06 | speachy | it's intended to trigger an exception that will halt the code |
| 10:59:18 | speachy | the os/etc can choose to ignore it in theory |
| 10:59:43 | braewoods | for RB though it means there's something serious going on probably |
| 10:59:53 | braewoods | since we don't use TRAPS and don't have "processes" |
| 11:00 |
| 11:00:06 | braewoods | so it is effectively a crash point |
| 11:01:04 | speachy | well, we _could_ handle it if we wrote the appropriate handler, but yeah, it's a deliberate crash point because the code will deliberately dereference a known-null pointer. |
| 11:02:55 | speachy | so these are masking a legit bug. maybe it's as simple as a pointer that's initialized to null but has a code path that can follow it before it's been initialized. |
| 11:03:14 | speachy | newer gcc has better diagnostics over this stuff. |
| 11:08:36 | braewoods | speachy: man embedded stuff like compiler guts seems to be poorly documented |
| 11:08:43 | braewoods | like why it uses trap #7 |
| 11:09:05 | braewoods | i find it in the source but no explaination how GCC chooses to use it |
| 11:09:16 | speachy | it's probably in a motorola architecture document somewher |
| 11:09:28 | braewoods | actually |
| 11:09:37 | speachy | or that was the trap used by example source code |
| 11:09:40 | braewoods | traps are entirely up to the ABI implementor how they are used |
| 11:09:52 | braewoods | the Amigas used the 68k differently |
| 11:09:56 | braewoods | traps |
| 11:09:59 | braewoods | even |
| 11:10:07 | *** | Saving seen data "./dancer.seen" |
| 11:10:53 | braewoods | hazard a guess, it has meaning to Linux m68k |
| 11:11:40 | braewoods | ok. Linux uses trap #0 for m68k |
| 11:11:43 | braewoods | for system calls |
| 11:12:41 | fs-bluebot_ | Build Server message: Build round completed after 1042 seconds. |
| 11:12:44 | fs-bluebot_ | Build Server message: Revision 61f6987 result: 5 errors 0 warnings |
| 11:13:40 | braewoods | i guess this is similar to the x86_64 syscall instruction or the i386 int 0x80 instruction |
| 11:14:06 | | Quit massiveH (Quit: Leaving) |
| 11:14:37 | braewoods | used some hand-coded ASM before but honestly i prefer working with C. juggling registers always made be a bit nervous. lol |
| 11:15:13 | speachy | look at g#2918 |
| 11:15:15 | fs-bluebot_ | Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : WIP: Fix potential null pointer dereferences by Solomon Peachy |
| 11:15:29 | speachy | this is what I had to change to get rid of the trap generated by a single function |
| 11:16:19 | braewoods | wow |
| 11:17:28 | speachy | the basic premise is that list->token isn't guaranteed to be not-null |
| 11:17:40 | speachy | (or rather, it's guaranteed to be null for some situations) |
| 11:18:09 | braewoods | is GCC just better at finding obscure situations? |
| 11:18:34 | speachy | each version gets better yet. |
| 11:19:53 | speachy | consider that skins require parsing user-supplied data, and yes, there's major openings for shenanigans |
| 11:20:16 | speachy | now the risk of actual malfesance is pretty low on these things, but still. |
| 11:22:14 | speachy | so yeah, I don't want to enable no-delete-null-pointer-checks globally just yet |
| 11:24:53 | braewoods | most of them don't even have networking so what would one gain from an exploit? |
| 11:25:03 | braewoods | the worst they can do it delete everything |
| 11:25:18 | speachy | we dont' care about exploits but we do care about crashes and data corruption. |
| 11:27:05 | braewoods | speachy: there's also a trap7 somewhere in the bootup sequence. i've reliably triggered it if i insert USB cable too soon or something. |
| 11:27:25 | speachy | there's a trap in the dircache code |
| 11:27:36 | braewoods | ah. |
| 11:29:50 | speachy | look at 2918 again, the dircache |
| 11:30:49 | speachy | if idx >=0, get_idx_dcvolp() will return NULL. but the loop terminates at idx = 0. |
| 11:32:32 | speachy | is the loop off-by-one, or should vol be checked for NULL? |
| 11:32:37 | speachy | ..I don't know. |
| 11:34:53 | speachy | braewoods: so congratulations, you stumbled into an entire network of rabbit holes. |
| 11:35:53 | speachy | even with that first change I made in the skin_data_free_buflib_allocs(), the actual bug might be that list->token isn't being set when it should be. |
| 11:41:29 | _bilgus | that seq fault happens when a sbs is applied I can tell its a NULL but still haven't found who exactly, bc its hard to track stuff through the theme engine |
| 11:41:52 | speachy | _bilgus: I'm attacking it from the other direction, I think. :/ |
| 11:43:22 | _bilgus | awesome maybe between us both we wil; find it, It really feels like deja vu |
| 11:43:42 | _bilgus | like I've chased and fixed this before |
| 11:45:52 | braewoods | unfortunately i don't think i can help there |
| 11:46:01 | braewoods | the rest of RB is somewhat beyond me right now |
| 11:46:26 | braewoods | it's best solved by someone that knows that code already |
| 11:46:30 | speachy | this is the first time I've seen any of this code too |
| 11:46:46 | speachy | but its original authors are long gone |
| 11:46:54 | speachy | leaving just us to pick up the pieces |
| 11:47:15 | _bilgus | and tromp through it till we understand it |
| 11:47:35 | braewoods | i may join you once i finish my current goals |
| 11:47:37 | speachy | (and the process create as many bugs as we fix) |
| 11:47:43 | _bilgus | so the loast one was AA thay was g#2540 |
| 11:47:45 | fs-bluebot_ | Gerrit review #2540 at http://gerrit.rockbox.org/r/2540 : mips: Adjust stack sizes by Solomon Peachy |
| 11:47:46 | speachy | (if we're lucky) |
| 11:48:57 | _bilgus | sorry thats g#2077 |
| 11:48:59 | fs-bluebot_ | Gerrit review #2077 at http://gerrit.rockbox.org/r/2077 : Fix skin_engine.c Album Art never dealloc'd on theme change by William Wilgus |
| 11:49:16 | _bilgus | there should be one more |
| 12:00 |
| 12:02:35 | braewoods | speachy: g#2919 g#2920 |
| 12:02:39 | fs-bluebot_ | Gerrit review #2919 at http://gerrit.rockbox.org/r/2919 : iriver_flash: remove trailing whitespaces by James Buren |
| 12:02:39 | fs-bluebot_ | Gerrit review #2920 at http://gerrit.rockbox.org/r/2920 : iriver_flash: make cfi_read_id use FB directly by James Buren |
| 12:03:18 | braewoods | funny story. when i started with frugalware i'm the reason they ended up adding whitespace checks to their lint scripts. i didn't understand what that meant at the time. |
| 12:16:56 | | Join toffe82 [0] (~kvirc@maf.wirelesstcp.net) |
| 12:23:25 | fs-bluebot_ | Build Server message: New build round started. Revision bee736f, 293 builds, 9 clients. |
| 12:26:25 | _bilgus | ok I traced it down to the backdrop code I need to look at it and see exactly why, maybe its not restoring the proper buffer |
| 12:27:02 | | Quit wodz_home (Ping timeout: 258 seconds) |
| 12:33:02 | | Part toffe82 ("Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is") |
| 12:34:58 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 12:36:05 | mendel_munkis | _bilgus: if you're going through the relevant code do you mind taking a look at FS #12899? |
| 12:36:07 | fs-bluebot_ | http://www.rockbox.org/tracker/task/12899 [fuze+] screen jumps navigating in upside-down mode (bugs, new) |
| 12:39:41 | | Quit Stanley00 (Ping timeout: 258 seconds) |
| 12:43:55 | fs-bluebot_ | Build Server message: Build round completed after 1231 seconds. |
| 12:43:56 | fs-bluebot_ | Build Server message: Revision bee736f result: 7 errors 0 warnings |
| 12:44:58 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 13:00 |
| 13:05:30 | | Join tchan1 [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net) |
| 13:07:08 | | Quit tchan (Ping timeout: 272 seconds) |
| 13:10:09 | *** | Saving seen data "./dancer.seen" |
| 13:14:22 | _bilgus | mendel_munkis, doubt its related but I have one to test so i'll put it on the list |
| 13:16:49 | | Quit tchan1 (Quit: WeeChat 2.8) |
| 13:17:08 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 13:20:40 | braewoods | man that was different |
| 13:21:13 | braewoods | this noob came into #learnprogramming about a C# question. their issue is they didn't understand they had to initialize the list they were trying to add elements to before they could add to it. |
| 13:21:27 | braewoods | it was embedded in another class so they assumed it was already initialized |
| 13:21:55 | braewoods | i'm no C# expert but i still can help with elementary questions like that. |
| 13:41:27 | speachy | ok, g#2918 updated. All known traps/etc in the core are fixed. |
| 13:41:31 | fs-bluebot_ | Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : WIP: Fix multiple null pointer dereferences by Solomon Peachy |
| 14:00 |
| 14:06:46 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 14:08:40 | _bilgus | speachy does this fix the issue I'm currently chasing? |
| 14:09:27 | speachy | _bilgus: no idea. |
| 14:10:30 | _bilgus | oh I should probably check then |
| 14:12:34 | _bilgus | atm its in the backdrop code Idk if someone references it after its freed it has a ref counter and doesn't seem to be getting freed early buttt |
| 14:14:11 | _bilgus | no dice was wort a try ;P |
| 14:19:41 | _bilgus | I'm pretty sure gcc is rightfully concerned though |
| 14:20:35 | speachy | I've fixed everything but one case in the lua plugin and one case in the wmapro codec. |
| 14:24:04 | _bilgus | oh whats the one in lua I'm normally pretty good about that |
| 14:24:43 | speachy | it's in luaG_runerror |
| 14:25:29 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 14:28:14 | _bilgus | oh thats lua core then |
| 14:30:00 | | Quit Airwave (Quit: WeeChat 2.3) |
| 14:35:54 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 14:40:24 | | Quit Stanley00 (Ping timeout: 240 seconds) |
| 14:49:30 | fs-bluebot_ | Build Server message: New build round started. Revision 7dbfda6, 293 builds, 9 clients. |
| 14:52:47 | | Quit pamaury (Ping timeout: 265 seconds) |
| 15:00 |
| 15:04:35 | fs-bluebot_ | Build Server message: Build round completed after 906 seconds. |
| 15:04:37 | fs-bluebot_ | Build Server message: Revision 7dbfda6 result: All green |
| 15:10:11 | *** | Saving seen data "./dancer.seen" |
| 15:18:22 | _bilgus | Speachy I just found it |
| 15:18:41 | _bilgus | well I just fond why I need to figure out who |
| 15:19:19 | _bilgus | I bounded the elems in fb_get_address and crash is gone |
| 15:19:44 | _bilgus | now who is calling the fb with values outside the screen size? |
| 15:24:17 | _bilgus | lcd_color_common ln 81 return fb->fb_ptr + (element % fb->elems); |
| 15:24:48 | _bilgus | I'll be back later and try to figure out who and what |
| 15:25:53 | | Quit petur (Quit: Connection reset by beer) |
| 15:26:47 | _bilgus | could also be someone expecting a bigger buffer than is currently selected but it should be kinda easy to figure out whom |
| 15:34:05 | | Join Airwave [0] (~Airwave@ti0006a400-0518.bb.online.no) |
| 15:44:20 | braewoods | speachy: next time i need to do is find out if flash operations works the same in the H300... |
| 15:44:49 | braewoods | start with some semi-safe tests to see if erase / program works in unused regions |
| 15:45:13 | braewoods | the ROM this time around is much larger than the OF uses |
| 15:45:32 | braewoods | it only uses around 63% of the space |
| 15:45:55 | braewoods | gives RB plenty of space at least |
| 15:46:09 | braewoods | around 1.9 MB of space |
| 15:46:11 | braewoods | if flashed to rom |
| 15:46:15 | braewoods | for both the ram/rom images |
| 15:46:32 | braewoods | they're currently around 700KB |
| 15:46:40 | braewoods | more than enough for future expansion |
| 15:46:50 | braewoods | provided the H300s survive that long. :> |
| 15:47:42 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 16:00 |
| 16:08:38 | | Join wodz_home [0] (~wodz@89-64-78-138.dynamic.chello.pl) |
| 16:14:18 | speachy | ok, I'd appreciate it if g#2918 can be sanity-checked. |
| 16:14:20 | fs-bluebot_ | Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : Fix multiple potential null pointer dereferences by Solomon Peachy |
| 16:19:56 | braewoods | by me? |
| 16:20:25 | speachy | by anyone other than myself. in the last iteration I caught a couple of logic goofs. |
| 16:22:36 | braewoods | so the problem with get_file_serialhash was... |
| 16:22:39 | braewoods | idx can be 0? |
| 16:23:15 | speachy | the problem is the final line; get_idx_dcvolp() returns NULL for idx=0 |
| 16:23:40 | braewoods | so idx is invalid if 0? |
| 16:23:45 | speachy | yeah. |
| 16:24:12 | braewoods | so why do we put >= then? |
| 16:24:18 | speachy | the idea is that when you get into negative indexes, it refers directly to the storage volume rather than the directory level. '0' is the root directory of that volume. |
| 16:24:24 | speachy | (if I understand the code correctly) |
| 16:24:40 | braewoods | i see. |
| 16:24:47 | braewoods | 0 should still be valid then |
| 16:24:49 | | Quit pamaury (Ping timeout: 264 seconds) |
| 16:25:08 | speachy | so your entry at level 0 is the root dir, and will have ->up pointing at a negative number. |
| 16:25:28 | braewoods | because it has no real parent directory |
| 16:25:33 | speachy | exactly |
| 16:25:46 | braewoods | so negatives are a sentinel value |
| 16:25:51 | braewoods | a substitute for null |
| 16:26:09 | speachy | yup, they're a sentinel that's translated by get_idx_dcvolp() |
| 16:26:42 | braewoods | so that gets called on a negative value then |
| 16:26:57 | braewoods | reversi seems simple |
| 16:27:27 | braewoods | the classic null coalesce check |
| 16:27:31 | braewoods | or so |
| 16:27:38 | braewoods | if(p && p->... |
| 16:28:18 | braewoods | just remembered how you can trigger branching with boolean AND/OR due to how C uses them |
| 16:28:34 | braewoods | it has to use branching to achieve short-circuit evaluation |
| 16:29:15 | braewoods | i mean at least if there's possible side-effects |
| 16:29:43 | braewoods | side-effect free expressions you can choose to branch or not; execution of them or not doesn't matter (at least at the symbolic level) |
| 16:30:06 | braewoods | still... no idea what compilers actually choose to do |
| 16:30:24 | braewoods | i still find short-circuit very valuable. i can't imagine programming without it. |
| 16:30:54 | braewoods | mostly it's used to conditionally perform a check or so that may be hazardous to perform if its assumptions are violated |
| 16:31:26 | braewoods | ah. |
| 16:31:32 | braewoods | chessbox pl_malloc |
| 16:31:36 | braewoods | let me guess... |
| 16:31:53 | braewoods | it's checking for possible memory exhaustion now |
| 16:31:57 | braewoods | instead of assuming it always works |
| 16:33:41 | braewoods | speachy: one criticism that probably won't matter for this too much. your code introduces a new problem, at least if this pl_malloc works the way i suspect it does |
| 16:33:51 | braewoods | memory leaks if any of these fail |
| 16:34:05 | braewoods | of course it may be moot if rockbox can reclaim it when the plugin exits |
| 16:34:19 | speachy | yeah, rockbox does reclaim it upon plugin termination |
| 16:34:57 | speachy | but if the malloc fails it's crashy crashy town anyway, so at least we'll be a little more robust now. |
| 16:35:21 | speachy | (ie it's a legit bug, whether or not we care is another matter) |
| 16:35:28 | braewoods | you can't guarantee execution there so it's probably better to crash the plugin rather than RB itself |
| 16:35:47 | braewoods | there's not much you can do once you hit OOM situations |
| 16:36:02 | braewoods | it's better to avoid it but |
| 16:36:05 | speachy | tbh it would be quite challenging to OOM the chesbox plugin |
| 16:36:06 | braewoods | only so much you can do. |
| 16:36:24 | braewoods | yea... it's better to preallocate instead of relying on malloc if you can. |
| 16:36:31 | braewoods | but the flexibility malloc offers is sometimes worth the cost |
| 16:36:55 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 16:36:57 | speachy | it's a port of an existing codebase, so yeah. |
| 16:37:16 | braewoods | i mainly prefer stack/fixed allocations whenever possible due to their high efficiency with ram usage |
| 16:37:51 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 16:37:56 | braewoods | speachy: is recursion used much in RB? i would hope not due to the limited stack size. |
| 16:38:10 | braewoods | it's the most common way to cause stack overflow |
| 16:38:17 | speachy | it's not used much. |
| 16:38:29 | braewoods | iterative solutions are usually better |
| 16:38:31 | speachy | but again, plugins tend to contain substantial 3rd-party code |
| 16:38:41 | braewoods | i see. |
| 16:38:47 | speachy | our stacks are a lot more limited than our heap |
| 16:38:57 | braewoods | like 256K or so? |
| 16:39:06 | braewoods | that was the IRAM for coldfire |
| 16:39:07 | braewoods | or so |
| 16:39:18 | braewoods | it seems the stack is allocated out of the fast RAM segments if any |
| 16:39:29 | speachy | IRAM on the coldfire is ~48K. |
| 16:39:34 | braewoods | Oh |
| 16:39:36 | braewoods | 0xc000 |
| 16:39:38 | braewoods | right |
| 16:39:40 | braewoods | ok |
| 16:39:45 | speachy | I think our main stack is 8K. |
| 16:40:04 | braewoods | so need to be careful about large string buffers and such |
| 16:40:06 | speachy | the codec stack goes there too for speed |
| 16:40:40 | speachy | since the coldfire doesn't have a data cache. |
| 16:40:46 | braewoods | on Linux i routinely use large ass string buffers |
| 16:40:56 | braewoods | 4K or so |
| 16:41:01 | braewoods | that would utterly crush RB |
| 16:41:03 | braewoods | lol |
| 16:41:27 | braewoods | i guess since when the systems i program for on the desktop have 1+ GB RAM |
| 16:41:36 | braewoods | i don't tend to consider 4K a lot to as kfor. |
| 16:41:37 | | Quit Stanley00 (Ping timeout: 264 seconds) |
| 16:41:43 | braewoods | and process stack limits are like 8MB |
| 16:41:45 | braewoods | so |
| 16:41:49 | speachy | your desktop CPU has more cache than a typical rockbox target has RAM. :) |
| 16:42:53 | braewoods | i'm still using ivy bridge laptops that have been fully maxed out |
| 16:42:59 | braewoods | 16G RAM, SSDs. |
| 16:51:33 | | Quit Barlow (Quit: leaving) |
| 16:58:41 | | Quit funman (*.net *.split) |
| 16:58:49 | | Join funman [0] (~fun@chui-pas.net) |
| 17:00 |
| 17:01:18 | braewoods | speachy: in statusbar-skinned... seems fine but i noticed it could be an application of the ternary operator |
| 17:02:04 | braewoods | it seems to just depends on the value of one variable and you want it set in either case |
| 17:02:26 | braewoods | i often use the GNU extension to the ternary operator at times |
| 17:02:40 | braewoods | char* s = foo ?: "" |
| 17:02:42 | braewoods | etc |
| 17:02:51 | braewoods | empty string if null |
| 17:08:06 | braewoods | speachy: i think i need to rework the method the flash routines use for waiting for the FLASH to signal completion. |
| 17:08:14 | braewoods | it uses code that's totally different from the datasheet. |
| 17:08:39 | braewoods | the datasheets say you need to inspect either the toggle bit or data poll pin |
| 17:09:08 | braewoods | and the method is the same for both erase/program |
| 17:09:24 | braewoods | so i think i will make it into a subroutine to reduce code duplication |
| 17:10:13 | *** | Saving seen data "./dancer.seen" |
| 17:12:08 | | Join Barlow [0] (~barlow@unaffiliated/barlow) |
| 17:22:08 | | Quit pamaury (Ping timeout: 265 seconds) |
| 17:54:02 | | Quit funman (Changing host) |
| 17:54:02 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 18:00 |
| 18:24:31 | lebellium | speachy: a patch about WMA Pro. So 2000's :D |
| 18:33:38 | speachy | I started pulling in upstream fixes after the obvious source of the trap continuted to elude me |
| 18:34:07 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 18:35:04 | | Quit wodz_home (Ping timeout: 256 seconds) |
| 18:38:09 | braewoods | speachy: suggestions for how I can delay 1 us? |
| 18:38:23 | speachy | udelay(1) ? :) |
| 18:38:31 | braewoods | that's a RB feature? |
| 18:38:35 | speachy | most targets have a udelay() function |
| 18:38:43 | speachy | (probably all) |
| 18:39:19 | | Quit Stanley00 (Ping timeout: 260 seconds) |
| 18:39:43 | braewoods | just the datasheet for the newer rom chip says to delay 1us after completion to allow the chip to resume normal operation |
| 18:39:55 | | Quit Rower (Ping timeout: 246 seconds) |
| 18:39:57 | braewoods | so i plan to wait for both cases since it won't hurt the older one |
| 18:40:42 | braewoods | sleep works for larger units |
| 18:40:49 | braewoods | but is rather limited for really small ones |
| 18:41:24 | braewoods | it doesn't appear coldfire has one |
| 18:41:26 | braewoods | hm |
| 18:41:34 | braewoods | testing that assumption |
| 18:42:16 | | Quit lebellium (Quit: Leaving) |
| 18:43:02 | | Quit emacsomancer (Read error: Connection reset by peer) |
| 18:44:08 | braewoods | thought so |
| 18:44:11 | braewoods | no udelay |
| 18:44:57 | braewoods | some have it most don't |
| 18:45:11 | braewoods | it's alls mips or arm ones |
| 18:45:33 | braewoods | i guess i'm not surprised. there's usually no need for something like usleep in the regular software. |
| 18:46:32 | braewoods | rofl this is weird looking |
| 18:46:40 | braewoods | the PP system header has... |
| 18:46:48 | braewoods | the same macro definitions on both ends of the conditionals |
| 18:46:53 | braewoods | what's up with that? |
| 18:47:42 | speachy | I believe the term for that is "technical baggage" |
| 18:48:21 | braewoods | i see. |
| 18:54:59 | | Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) |
| 19:00 |
| 19:10:14 | *** | Saving seen data "./dancer.seen" |
| 19:19:59 | braewoods | hm |
| 19:20:05 | braewoods | need to find a way to delay in microseconds |
| 19:20:08 | braewoods | instead of nanoseconds |
| 19:20:11 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 19:20:11 | * | braewoods facepalms. |
| 19:20:20 | braewoods | 1 us |
| 19:20:21 | braewoods | not ms |
| 19:20:30 | braewoods | but rb's normal sleep is |
| 19:20:50 | braewoods | at best |
| 19:20:52 | braewoods | 10 ms |
| 19:20:56 | braewoods | in smallest unit |
| 19:21:01 | braewoods | 10,000 us |
| 19:29:09 | __builtin | we have udelay |
| 19:29:43 | braewoods | i'd use it but it's not available on coldfire |
| 19:29:47 | __builtin | although I think it's target-specific |
| 19:30:15 | braewoods | honestly i'm surprised it's not exported as a standard function. |
| 19:30:24 | braewoods | it can be very usefu |
| 19:30:34 | braewoods | like if you need to wait for hardware |
| 19:31:47 | braewoods | to do a delay loop i need... |
| 19:31:52 | braewoods | 4 instructions |
| 19:32:14 | braewoods | whatever CF uses for comparison |
| 19:32:20 | braewoods | an integer register |
| 19:32:35 | braewoods | add, cmp, jmp... |
| 19:32:45 | braewoods | jmp if not equal |
| 19:32:48 | braewoods | or w/e |
| 19:32:53 | braewoods | so i guess |
| 19:32:55 | braewoods | 3 |
| 19:45:12 | | Quit pixelma (Ping timeout: 260 seconds) |
| 19:45:12 | | Quit amiconn (Ping timeout: 260 seconds) |
| 20:00 |
| 20:04:57 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 20:05:54 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 20:12:12 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 20:12:12 | | Join fs-bluebot [0] (~fs-bluebo@55d46dc5.access.ecotel.net) |
| 20:14:38 | | Quit fs-bluebot_ (Ping timeout: 272 seconds) |
| 20:15:54 | | Quit bluebrother^ (Ping timeout: 272 seconds) |
| 20:33:42 | | Quit MrZeus (Read error: No route to host) |
| 20:35:11 | | Join MrZeus [0] (~MrZeus@90.203.212.4) |
| 20:52:23 | | Quit livvy (Ping timeout: 240 seconds) |
| 21:00 |
| 21:00:37 | | Quit vvrng (Ping timeout: 246 seconds) |
| 21:10:15 | *** | Saving seen data "./dancer.seen" |
| 21:49:00 | | Quit MrZeus (Ping timeout: 272 seconds) |
| 21:59:12 | fs-bluebot | Build Server message: New build round started. Revision a5a19a3, 293 builds, 9 clients. |
| 22:00 |
| 22:16:52 | | Join saratoga [0] (620acd42@cpe-98-10-205-66.rochester.res.rr.com) |
| 22:18:52 | fs-bluebot | Build Server message: Build round completed after 1180 seconds. |
| 22:18:54 | fs-bluebot | Build Server message: Revision a5a19a3 result: 3 errors 0 warnings |
| 22:18:55 | fs-bluebot | Build Server message: New build round started. Revision bcbf8bb, 293 builds, 8 clients. |
| 22:38:59 | fs-bluebot | Build Server message: Build round completed after 1204 seconds. |
| 22:39:00 | fs-bluebot | Build Server message: Revision bcbf8bb result: All green |
| 22:42:41 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 22:42:42 | | Quit Stanley00 (Remote host closed the connection) |
| 22:43:19 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 22:53:54 | braewoods | speachy: https://gerrit.rockbox.org/#/c/rockbox/+/2925 |
| 22:55:49 | braewoods | strange time. first time i ever really used volatile. |
| 22:55:50 | | Quit beencubed (Quit: Leaving) |
| 23:00 |
| 23:10:17 | *** | Saving seen data "./dancer.seen" |
| 23:15:16 | saratoga | wow a WMA commit, that takes me back |
| 23:20:23 | braewoods | WMA? |
| 23:24:44 | braewoods | Oh. |
| 23:57:39 | speachy | saratoga: didn't fix the "bug" I was hunting but I figured fixing a few CVEs and generally making things more robust wouldn't hurt. |
icon identifies that the person is a core developer (has commit access).