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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2020-10-27

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_bilguseverything
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:29edhelas_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:05wodz_homespeachy: 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:21speachywodz_home: oh, niiice.
07:27:27speachywhen you do the aplay -D, can you include a −−dump-hw-params to see what the raw capabilities are?
07:28:09speachy(since they are presumably going to be different than the native pcm codec..)
07:28:14wodz_homeThe 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:22wodz_homesure, wait a sec
07:29:12speachybilgus is sorta working on a prototype UI, keeps getting distracted by our past sins. :)
07:31:31wodz_homeHW Params of device "bluetooth:ADDRESS=80:C7:55:63:59:D6":
07:31:31wodz_home−−−−−−−−−−−−−−−−−−−−
07:31:31wodz_homeACCESS: MMAP_INTERLEAVED MMAP_NONINTERLEAVED MMAP_COMPLEX RW_INTERLEAVED RW_NONINTERLEAVED
07:31:31DBUGEnqueued KICK wodz_home
07:31:31wodz_homeFORMAT: 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:31wodz_homeSUBFORMAT: STD
07:31:33wodz_homeSAMPLE_BITS: [4 64]
07:31:35wodz_homeFRAME_BITS: [4 640000]
07:31:37wodz_homeCHANNELS: [1 10000]
07:31:39wodz_homeRATE: [4000 4294967295)
07:31:41wodz_homePERIOD_TIME: (10666 256000]
07:31:43wodz_homePERIOD_SIZE: (42 1099511628)
07:31:47wodz_homePERIOD_BYTES: (21 4294967295)
07:31:49wodz_homePERIODS: (0 78536545)
07:31:51wodz_homeBUFFER_TIME: [1 4294967295]
07:31:53wodz_homeBUFFER_SIZE: [512 3298534882]
07:31:55wodz_homeBUFFER_BYTES: [256 4294967295]
07:31:57wodz_homeTICK_TIME: ALL
07:31:59wodz_home−−−−−−−−−−−−−−−−−−−−
07:32:01wodz_homeALSA lib audio/pcm_bluetooth.c:2056:(audioservice_recv) Too short (0 bytes) IPC packet from bluetoothd
07:32:03wodz_homeaplay: set_params:1166: Unable to install hw params:
07:32:05wodz_homeACCESS: RW_INTERLEAVED
07:32:07wodz_homeFORMAT: S16_LE
07:32:09wodz_homeSUBFORMAT: STD
07:32:11wodz_homeSAMPLE_BITS: 16
07:32:13wodz_homeFRAME_BITS: 32
07:32:17wodz_homeCHANNELS: 2
07:32:19wodz_homeRATE: 44100
07:32:21wodz_homePERIOD_TIME: (46439 46440)
07:32:23wodz_homePERIOD_SIZE: 2048
07:32:25wodz_homePERIOD_BYTES: 8192
07:32:27wodz_homePERIODS: 3
07:32:29wodz_homeBUFFER_TIME: (139319 139320)
07:32:31wodz_homeBUFFER_SIZE: 6144
07:32:33wodz_homeBUFFER_BYTES: 24576
07:32:35wodz_homeTICK_TIME: 0
07:33:01wodz_homespeachy: ^
07:33:04speachyso in other words, the alsa bluetooth lib will translate from anything to whatever the hw needs.
07:33:14wodz_homeseems so
07:33:25speachybut it's probably best to lock it to 44 &| 48 KHz.
07:36:09speachywodz_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:42wodz_homebut do we need this considering bluetooth alsa device can ingest anything?
07:40:22speachymore of a cpu optimization. no sense in rendering at 192KHz with full DSP if it's going to get thrown out
07:40:52speachyand on that note, time to see the dentist.
07:40:56wodz_homeahh, 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:09speachybraewoods: 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:04braewoodsspeachy: perhaps.
10:39:34speachy(ie the theme/skin/whatever pointers can't legitimately be null, or badness will happen)
10:41:19speachythis might be releated to the theme reload segfault that bilgus ran into on the rocker
10:41:57braewoodsmaybe the m68k code gen notices these more
10:42:06braewoodssince it seems to trigger TRAPs for those
10:42:30braewoodstrap #7 specifically
10:42:45braewoodsbut we don't use traps so it needs to be disabled in some cases where this is legit behavior
10:43:07braewoodsbut those are few
10:43:22braewoodsmostly stuff that needs direct HW access
10:43:47braewoodsspeachy: https://gerrit.rockbox.org/r/#/c/rockbox/+/2917/ <−− i removed the extra whitespace in this patch
10:44:37braewoodsi'll look for more traps later but i was just investigating whether the bootloaders might have the same problem
10:44:39braewoodsthey don't.
10:44:58braewoodsthey're low level stuff so i thought it should be investigated
10:44:58speachyaha! found a 'udf' in the nano2g disasm, same place.
10:45:06braewoodsudf?
10:45:14speachythe other targets I was looking at were 1/2bit screens
10:45:20speachy'undefined' instruction
10:45:29speachyso it's not m68k-specific.
10:45:34speachyok, gonna try an experiment.
10:46:19braewoodsiirc, the LK's issue with this GCC additions was code like
10:46:20speachybacking off before the viewport rework, and see if it still generates the trap/udf
10:46:35braewoods(const struct ...* foo)
10:46:42braewoodssize_t x = foo->size;
10:46:48braewoodsif(foo == NULL) { ... }
10:46:51braewoodsit would omit the if
10:46:59braewoodsassumes foo cannot be null
10:47:12speachyyeah.
10:47:14braewoodschecking after a dereference
10:47:29 Quit pamaury (Quit: Konversation terminated!)
10:48:04speachyyeah, it's there prior to the viewport rejigger.
10:48:05braewoodsif you're doing embedded, it doesn't matter so much, but in userspace C, it's illogical to do that.
10:48:56speachyso the odds are good that this has been a problem for all mips and hosted arm for a while now.
10:49:20braewoodsand coldfire was just the first to expose it in an obvious instruction?
10:49:55speachywell, you tripped over it in the flash tool (which is a rare legitimate use for null pointer dereferences)
10:52:56speachythe stuff you found in the skin code is clearly due to bugs.
10:53:19speachythe trick is unwinding the tortuous path the gcc optimizer used to make that determination
10:55:20fs-bluebot_Build Server message: New build round started. Revision 61f6987, 293 builds, 9 clients.
10:57:18speachya bunch of plugins have 'trap #15' in 'em
10:58:36braewoodsi'm going to look through gcc source code. what does it use traps for?
10:59:06speachyit's intended to trigger an exception that will halt the code
10:59:18speachythe os/etc can choose to ignore it in theory
10:59:43braewoodsfor RB though it means there's something serious going on probably
10:59:53braewoodssince we don't use TRAPS and don't have "processes"
11:00
11:00:06braewoodsso it is effectively a crash point
11:01:04speachywell, 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:55speachyso 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:14speachynewer gcc has better diagnostics over this stuff.
11:08:36braewoodsspeachy: man embedded stuff like compiler guts seems to be poorly documented
11:08:43braewoodslike why it uses trap #7
11:09:05braewoodsi find it in the source but no explaination how GCC chooses to use it
11:09:16speachyit's probably in a motorola architecture document somewher
11:09:28braewoodsactually
11:09:37speachyor that was the trap used by example source code
11:09:40braewoodstraps are entirely up to the ABI implementor how they are used
11:09:52braewoodsthe Amigas used the 68k differently
11:09:56braewoodstraps
11:09:59braewoodseven
11:10:07***Saving seen data "./dancer.seen"
11:10:53braewoodshazard a guess, it has meaning to Linux m68k
11:11:40braewoodsok. Linux uses trap #0 for m68k
11:11:43braewoodsfor system calls
11:12:41fs-bluebot_Build Server message: Build round completed after 1042 seconds.
11:12:44fs-bluebot_Build Server message: Revision 61f6987 result: 5 errors 0 warnings
11:13:40braewoodsi 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:37braewoodsused some hand-coded ASM before but honestly i prefer working with C. juggling registers always made be a bit nervous. lol
11:15:13speachylook atg#2918
11:15:15fs-bluebot_Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : WIP: Fix potential null pointer dereferences by Solomon Peachy
11:15:29speachythis is what I had to change to get rid of the trap generated by a single function
11:16:19braewoodswow
11:17:28speachythe basic premise is that list->token isn't guaranteed to be not-null
11:17:40speachy(or rather, it's guaranteed to be null for some situations)
11:18:09braewoodsis GCC just better at finding obscure situations?
11:18:34speachyeach version gets better yet.
11:19:53speachyconsider that skins require parsing user-supplied data, and yes, there's major openings for shenanigans
11:20:16speachynow the risk of actual malfesance is pretty low on these things, but still.
11:22:14speachyso yeah, I don't want to enable no-delete-null-pointer-checks globally just yet
11:24:53braewoodsmost of them don't even have networking so what would one gain from an exploit?
11:25:03braewoodsthe worst they can do it delete everything
11:25:18speachywe dont' care about exploits but we do care about crashes and data corruption.
11:27:05braewoodsspeachy: 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:25speachythere's a trap in the dircache code
11:27:36braewoodsah.
11:29:50speachylook at 2918 again, the dircache
11:30:49speachyif idx >=0, get_idx_dcvolp() will return NULL. but the loop terminates at idx = 0.
11:32:32speachyis the loop off-by-one, or should vol be checked for NULL?
11:32:37speachy..I don't know.
11:34:53speachybraewoods: so congratulations, you stumbled into an entire network of rabbit holes.
11:35:53speachyeven 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_bilgusthat 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:52speachy_bilgus: I'm attacking it from the other direction, I think. :/
11:43:22_bilgusawesome maybe between us both we wil; find it, It really feels like deja vu
11:43:42_bilguslike I've chased and fixed this before
11:45:52braewoodsunfortunately i don't think i can help there
11:46:01braewoodsthe rest of RB is somewhat beyond me right now
11:46:26braewoodsit's best solved by someone that knows that code already
11:46:30speachythis is the first time I've seen any of this code too
11:46:46speachybut its original authors are long gone
11:46:54speachyleaving just us to pick up the pieces
11:47:15_bilgusand tromp through it till we understand it
11:47:35braewoodsi may join you once i finish my current goals
11:47:37speachy(and the process create as many bugs as we fix)
11:47:43_bilgusso the loast one was AA thay wasg#2540
11:47:45fs-bluebot_Gerrit review #2540 at http://gerrit.rockbox.org/r/2540 : mips: Adjust stack sizes by Solomon Peachy
11:47:46speachy(if we're lucky)
11:48:57_bilgussorry thatsg#2077
11:48:59fs-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_bilgusthere should be one more
12:00
12:02:35braewoodsspeachy:g#2919g#2920
12:02:39fs-bluebot_Gerrit review #2919 at http://gerrit.rockbox.org/r/2919 : iriver_flash: remove trailing whitespaces by James Buren
12:02:39fs-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:18braewoodsfunny 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:25fs-bluebot_Build Server message: New build round started. Revision bee736f, 293 builds, 9 clients.
12:26:25_bilgusok 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:05mendel_munkis_bilgus: if you're going through the relevant code do you mind taking a look at FS #12899?
12:36:07fs-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:55fs-bluebot_Build Server message: Build round completed after 1231 seconds.
12:43:56fs-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_bilgusmendel_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:40braewoodsman that was different
13:21:13braewoodsthis 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:27braewoodsit was embedded in another class so they assumed it was already initialized
13:21:55braewoodsi'm no C# expert but i still can help with elementary questions like that.
13:41:27speachyok,g#2918 updated. All known traps/etc in the core are fixed.
13:41:31fs-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_bilgusspeachy does this fix the issue I'm currently chasing?
14:09:27speachy_bilgus: no idea.
14:10:30_bilgusoh I should probably check then
14:12:34_bilgusatm 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_bilgusno dice was wort a try ;P
14:19:41_bilgusI'm pretty sure gcc is rightfully concerned though
14:20:35speachyI've fixed everything but one case in the lua plugin and one case in the wmapro codec.
14:24:04_bilgusoh whats the one in lua I'm normally pretty good about that
14:24:43speachyit's in luaG_runerror
14:25:29 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
14:28:14_bilgusoh 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:30fs-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:35fs-bluebot_Build Server message: Build round completed after 906 seconds.
15:04:37fs-bluebot_Build Server message: Revision 7dbfda6 result: All green
15:10:11***Saving seen data "./dancer.seen"
15:18:22_bilgusSpeachy I just found it
15:18:41_bilguswell I just fond why I need to figure out who
15:19:19_bilgusI bounded the elems in fb_get_address and crash is gone
15:19:44_bilgusnow who is calling the fb with values outside the screen size?
15:24:17_bilguslcd_color_common ln 81 return fb->fb_ptr + (element % fb->elems);
15:24:48_bilgusI'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_bilguscould 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:20braewoodsspeachy: next time i need to do is find out if flash operations works the same in the H300...
15:44:49braewoodsstart with some semi-safe tests to see if erase / program works in unused regions
15:45:13braewoodsthe ROM this time around is much larger than the OF uses
15:45:32braewoodsit only uses around 63% of the space
15:45:55braewoodsgives RB plenty of space at least
15:46:09braewoodsaround 1.9 MB of space
15:46:11braewoodsif flashed to rom
15:46:15braewoodsfor both the ram/rom images
15:46:32braewoodsthey're currently around 700KB
15:46:40braewoodsmore than enough for future expansion
15:46:50braewoodsprovided 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:18speachyok, I'd appreciate it ifg#2918 can be sanity-checked.
16:14:20fs-bluebot_Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : Fix multiple potential null pointer dereferences by Solomon Peachy
16:19:56braewoodsby me?
16:20:25speachyby anyone other than myself. in the last iteration I caught a couple of logic goofs.
16:22:36braewoodsso the problem with get_file_serialhash was...
16:22:39braewoodsidx can be 0?
16:23:15speachythe problem is the final line; get_idx_dcvolp() returns NULL for idx=0
16:23:40braewoodsso idx is invalid if 0?
16:23:45speachyyeah.
16:24:12braewoodsso why do we put >= then?
16:24:18speachythe 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:24speachy(if I understand the code correctly)
16:24:40braewoodsi see.
16:24:47braewoods0 should still be valid then
16:24:49 Quit pamaury (Ping timeout: 264 seconds)
16:25:08speachyso your entry at level 0 is the root dir, and will have ->up pointing at a negative number.
16:25:28braewoodsbecause it has no real parent directory
16:25:33speachyexactly
16:25:46braewoodsso negatives are a sentinel value
16:25:51braewoodsa substitute for null
16:26:09speachyyup, they're a sentinel that's translated by get_idx_dcvolp()
16:26:42braewoodsso that gets called on a negative value then
16:26:57braewoodsreversi seems simple
16:27:27braewoodsthe classic null coalesce check
16:27:31braewoodsor so
16:27:38braewoodsif(p && p->...
16:28:18braewoodsjust remembered how you can trigger branching with boolean AND/OR due to how C uses them
16:28:34braewoodsit has to use branching to achieve short-circuit evaluation
16:29:15braewoodsi mean at least if there's possible side-effects
16:29:43braewoodsside-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:06braewoodsstill... no idea what compilers actually choose to do
16:30:24braewoodsi still find short-circuit very valuable. i can't imagine programming without it.
16:30:54braewoodsmostly it's used to conditionally perform a check or so that may be hazardous to perform if its assumptions are violated
16:31:26braewoodsah.
16:31:32braewoodschessbox pl_malloc
16:31:36braewoodslet me guess...
16:31:53braewoodsit's checking for possible memory exhaustion now
16:31:57braewoodsinstead of assuming it always works
16:33:41braewoodsspeachy: 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:51braewoodsmemory leaks if any of these fail
16:34:05braewoodsof course it may be moot if rockbox can reclaim it when the plugin exits
16:34:19speachyyeah, rockbox does reclaim it upon plugin termination
16:34:57speachybut if the malloc fails it's crashy crashy town anyway, so at least we'll be a little more robust now.
16:35:21speachy(ie it's a legit bug, whether or not we care is another matter)
16:35:28braewoodsyou can't guarantee execution there so it's probably better to crash the plugin rather than RB itself
16:35:47braewoodsthere's not much you can do once you hit OOM situations
16:36:02braewoodsit's better to avoid it but
16:36:05speachytbh it would be quite challenging to OOM the chesbox plugin
16:36:06braewoodsonly so much you can do.
16:36:24braewoodsyea... it's better to preallocate instead of relying on malloc if you can.
16:36:31braewoodsbut the flexibility malloc offers is sometimes worth the cost
16:36:55 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
16:36:57speachyit's a port of an existing codebase, so yeah.
16:37:16braewoodsi 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:56braewoodsspeachy: is recursion used much in RB? i would hope not due to the limited stack size.
16:38:10braewoodsit's the most common way to cause stack overflow
16:38:17speachyit's not used much.
16:38:29braewoodsiterative solutions are usually better
16:38:31speachybut again, plugins tend to contain substantial 3rd-party code
16:38:41braewoodsi see.
16:38:47speachyour stacks are a lot more limited than our heap
16:38:57braewoodslike 256K or so?
16:39:06braewoodsthat was the IRAM for coldfire
16:39:07braewoodsor so
16:39:18braewoodsit seems the stack is allocated out of the fast RAM segments if any
16:39:29speachyIRAM on the coldfire is ~48K.
16:39:34braewoodsOh
16:39:36braewoods0xc000
16:39:38braewoodsright
16:39:40braewoodsok
16:39:45speachyI think our main stack is 8K.
16:40:04braewoodsso need to be careful about large string buffers and such
16:40:06speachythe codec stack goes there too for speed
16:40:40speachysince the coldfire doesn't have a data cache.
16:40:46braewoodson Linux i routinely use large ass string buffers
16:40:56braewoods4K or so
16:41:01braewoodsthat would utterly crush RB
16:41:03braewoodslol
16:41:27braewoodsi guess since when the systems i program for on the desktop have 1+ GB RAM
16:41:36braewoodsi don't tend to consider 4K a lot to as kfor.
16:41:37 Quit Stanley00 (Ping timeout: 264 seconds)
16:41:43braewoodsand process stack limits are like 8MB
16:41:45braewoodsso
16:41:49speachyyour desktop CPU has more cache than a typical rockbox target has RAM. :)
16:42:53braewoodsi'm still using ivy bridge laptops that have been fully maxed out
16:42:59braewoods16G 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:18braewoodsspeachy: in statusbar-skinned... seems fine but i noticed it could be an application of the ternary operator
17:02:04braewoodsit seems to just depends on the value of one variable and you want it set in either case
17:02:26braewoodsi often use the GNU extension to the ternary operator at times
17:02:40braewoodschar* s = foo ?: ""
17:02:42braewoodsetc
17:02:51braewoodsempty string if null
17:08:06braewoodsspeachy: i think i need to rework the method the flash routines use for waiting for the FLASH to signal completion.
17:08:14braewoodsit uses code that's totally different from the datasheet.
17:08:39braewoodsthe datasheets say you need to inspect either the toggle bit or data poll pin
17:09:08braewoodsand the method is the same for both erase/program
17:09:24braewoodsso 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:31lebelliumspeachy: a patch about WMA Pro. So 2000's :D
18:33:38speachyI 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:09braewoodsspeachy: suggestions for how I can delay 1 us?
18:38:23speachyudelay(1) ? :)
18:38:31braewoodsthat's a RB feature?
18:38:35speachymost targets have a udelay() function
18:38:43speachy(probably all)
18:39:19 Quit Stanley00 (Ping timeout: 260 seconds)
18:39:43braewoodsjust 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:57braewoodsso i plan to wait for both cases since it won't hurt the older one
18:40:42braewoodssleep works for larger units
18:40:49braewoodsbut is rather limited for really small ones
18:41:24braewoodsit doesn't appear coldfire has one
18:41:26braewoodshm
18:41:34braewoodstesting that assumption
18:42:16 Quit lebellium (Quit: Leaving)
18:43:02 Quit emacsomancer (Read error: Connection reset by peer)
18:44:08braewoodsthought so
18:44:11braewoodsno udelay
18:44:57braewoodssome have it most don't
18:45:11braewoodsit's alls mips or arm ones
18:45:33braewoodsi guess i'm not surprised. there's usually no need for something like usleep in the regular software.
18:46:32braewoodsrofl this is weird looking
18:46:40braewoodsthe PP system header has...
18:46:48braewoodsthe same macro definitions on both ends of the conditionals
18:46:53braewoodswhat's up with that?
18:47:42speachyI believe the term for that is "technical baggage"
18:48:21braewoodsi 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:59braewoodshm
19:20:05braewoodsneed to find a way to delay in microseconds
19:20:08braewoodsinstead of nanoseconds
19:20:11CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
19:20:11*braewoods facepalms.
19:20:20braewoods1 us
19:20:21braewoodsnot ms
19:20:30braewoodsbut rb's normal sleep is
19:20:50braewoodsat best
19:20:52braewoods10 ms
19:20:56braewoodsin smallest unit
19:21:01braewoods10,000 us
19:29:09__builtinwe have udelay
19:29:43braewoodsi'd use it but it's not available on coldfire
19:29:47__builtinalthough I think it's target-specific
19:30:15braewoodshonestly i'm surprised it's not exported as a standard function.
19:30:24braewoodsit can be very usefu
19:30:34braewoodslike if you need to wait for hardware
19:31:47braewoodsto do a delay loop i need...
19:31:52braewoods4 instructions
19:32:14braewoodswhatever CF uses for comparison
19:32:20braewoodsan integer register
19:32:35braewoodsadd, cmp, jmp...
19:32:45braewoodsjmp if not equal
19:32:48braewoodsor w/e
19:32:53braewoodsso i guess
19:32:55braewoods3
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:12fs-bluebotBuild 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:52fs-bluebotBuild Server message: Build round completed after 1180 seconds.
22:18:54fs-bluebotBuild Server message: Revision a5a19a3 result: 3 errors 0 warnings
22:18:55fs-bluebotBuild Server message: New build round started. Revision bcbf8bb, 293 builds, 8 clients.
22:38:59fs-bluebotBuild Server message: Build round completed after 1204 seconds.
22:39:00fs-bluebotBuild 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:54braewoodsspeachy: https://gerrit.rockbox.org/#/c/rockbox/+/2925
22:55:49braewoodsstrange 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:16saratogawow a WMA commit, that takes me back
23:20:23braewoodsWMA?
23:24:44braewoodsOh.
23:57:39speachysaratoga: didn't fix the "bug" I was hunting but I figured fixing a few CVEs and generally making things more robust wouldn't hurt.

Previous day | Next day