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

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

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

#rockbox log for 2021-07-20

00:01:55***Saving seen data "./dancer.seen"
00:19:16 Quit Romster (Ping timeout: 252 seconds)
00:23:54 Join Romster [0] (~romster@user/romster)
00:42:29 Quit advcomp2019 (Read error: Connection reset by peer)
00:42:52 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
01:00
01:12:28 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:49c1:bcff:9db4:f4aa)
02:00
02:01:59***Saving seen data "./dancer.seen"
02:04:21 Quit lebellium (Quit: Leaving)
02:27:31desowinCoverity Scan reported 915 issues, to view click add me to project at https://scan.coverity.com/projects/rockbox
02:32:10desowinsorting by impact, CID#353480 is real file handle leak when load_voicefile_index() returns false when file does exist but has malformed header, the fd is never closed
04:00
04:02:03***Saving seen data "./dancer.seen"
04:12:23 Join advcomp2019_ [0] (~advcomp20@user/advcomp2019)
04:15:24 Quit advcomp2019 (Ping timeout: 252 seconds)
04:27:20 Quit ufdm (Read error: Connection reset by peer)
04:27:28 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
04:35:31 Quit Romster (Ping timeout: 268 seconds)
04:37:12 Join Romster [0] (~romster@user/romster)
04:41:52 Join bittin [0] (~bittin@user/bittin)
04:41:58bittinhttps://www.youtube.com/watch?v=HJDY1FXuJPQ some Rockbox love on Youtube
05:00
05:35:36 Part bittin (Leaving)
05:55:05 Quit ufdm (Read error: Connection reset by peer)
05:55:17 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
06:00
06:02:05***Saving seen data "./dancer.seen"
06:09:00 Quit ufdm (Read error: Connection reset by peer)
06:52:24speachy_bilgus: no, because when path is null pathsize is 0, so the memcpy() does nothing.
06:54:02speachyGoing to the URL you mentioned it claims no builds were succsssfully analyzed.. don't have a way of looking at that report.
07:00
07:03:04speachy(didn't get an invite email either, FWIW)
07:03:16speachydesowin: ^^
07:10:32speachybut if the most severe issue is a fd leak, then we're doing better than I'd expected.
07:33:31speachy(a leak in a called-once-at-startup error path!)
07:37:55desowinthere are a bunch of out of bounds accesses...
07:39:29ArsenI suspect such a bug is behind what I'm debugging
07:39:55ArsenI may try to afford a USB sniffer to look into this further, as I said, but I'm not sure how viable that is, since as a student I have no income at all
07:40:25desowinif you study computer science, check if your faculty has one
07:42:33desowinwhen I was student, there was Ellisys USB Explorer 200 that I could access
07:42:40ArsenI will when I go back there, I finished up my work for this year and I'm with my parents rn
07:43:13Arsenthere's two unis in near proximity to me so I'll try on both, I know EE and CE students on both too
07:47:25speachythere's a bunch of USB 2.0 LeCroy Conquest units on ebay right now, but they're still $500ish.
07:50:36desowinOpenVizsla is probably the cheapest, with fairly good Wireshark support (of course, my opinion is biased as I wrote the dissector and ovextcap)
07:51:47desowinfor students, university equipment would be most affordable
07:53:44gevaertsBack in the very early days of my work on rockbox I happened to have a CATC (now LeCroy) box on my desk at work. It did help a lot...
07:57:06speachyA couple years back I picked up an ITI1480A unit for a specific debug task, and it paid for itself by pointing the finger squarely away from me. :D
07:58:04speachyI was disappointed that their attempt to crowdfund a USB3.0 version of it failed miserably...
07:58:48gevaertsWe (rockbox) do own a https://www.mqp.com/usb480.htm but (a) I don't know who has it currently (maybe pamaury?) and (b) it's not great, but if we find it it could be sent over to whoever needs it
07:59:40speachyhuh, did not know that
08:00
08:02:08***Saving seen data "./dancer.seen"
08:06:16speachyI have an openvizla board here; if I can get it to work I'll donate it to the rockbox cause.
08:07:32desowinis the ftdi programmed with OpenVizsla VID/PID or defaults?
08:08:04desowinbecause well, if it's programmed then it is trivial to get it running nowadays
08:08:27desowin(if not, then it's not a big deal unless there are still some soldering issues)
08:09:20speachyI think it's the latter, actually. that's why I got it for so cheap.
08:09:49desowinquick way to tell is to plug it and check how it enumerates (if at all)
08:09:49speachyI didn't have the time to debug it at the time but I still have it (and a second bare PCB)
08:10:32desowinwhen my colleague at work assembled one manually, the FTDI and RAM chips had to be resoldered
08:10:41speachydoesn't appear to enumerate at all.
08:10:59speachy(got it five years ago, so..)
08:11:19desowinsuprisingly the USB transceiver got soldered correctly first try
08:12:38desowinsilly question, but you plug it with the connector on the side where there's just one connector (to capture host)?
08:13:28speachyyes. the second time. :D
08:14:10speachycould also be the cable. one of my cats has this annoying habit of chewing on cables when I don't pay attention to her.
08:15:05speachyI'll take it into the lab at work and try to probe the FTDI chip during any downtime
08:16:29speachyaaand on that note, time to scoot.
08:16:33*speachy waves.
08:16:36 Quit speachy (Quit: WeeChat 3.0.1)
08:42:42 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
08:48:57 Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542)
09:00
09:14:24 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
09:47:26 Join Telehubis [0] (~Telehubis@dynamic-78-10-123-181.ssp.dialog.net.pl)
09:56:05TelehubisI managed to compile the code (what an achievement! ;- ) ). Searched for Shanling Q1 bootloader that Im after but in the bootloader its not there. Do I use a wrong complier? (used ARM)
10:00
10:02:09***Saving seen data "./dancer.seen"
10:02:19 Quit Telehubis (Quit: Connection closed)
10:19:49 Join amachronic [0] (~amachroni@user/amachronic)
10:21:13amachronicTelehubis: you need a MIPS compiler. in configure pick the Q1 and then 'b' for bootloader
10:24:45 Join Telehubis [0] (~Telehubis@dynamic-78-10-123-181.ssp.dialog.net.pl)
10:26:40Telehubisamachronic: dang, I think MIPS is currently not building under WIndows... (thats the info I found on compile Rockbox page)... Then need to wait untill it will be available :- )
10:31:38amachronicif ARM builds then MIPS should.... Did you try compiling it? (Also you need to use the MIPS native toolchain, not hosted.)
10:32:37 Quit massiveH (Quit: Leaving)
10:32:57rb-bluebotBuild Server message: New build round started. Revision 6f042e91dd, 303 builds, 8 clients.
10:40:12amachronicTelehubis: that statement on the wiki is 2 years old for no reason I can find so idk, maybe it's no longer applicable.
10:42:19amachronicI can give you a bootloader later today −− I'm happy to release it as-is, just let me merge g#3589 first
10:42:21rb-bluebotGerrit review #3589 at https://gerrit.rockbox.org/r/c/rockbox/+/3589 : jztool: add support for Shanling Q1 and Eros Q by Aidan MacDonald
10:42:58Telehubisamachronic: thanks!
10:43:42munkisis there any easy way to tell which build a builder last participated in?
10:45:17rb-bluebotBuild Server message: Build round completed after 740 seconds.
10:45:19rb-bluebotBuild Server message: Revision 6f042e91dd result: All green
10:45:34munkisjust noticed that uzziyah isn't building and am trying to figureout why.
10:56:59rb-bluebotBuild Server message: New build round started. Revision 740a50687f, 303 builds, 8 clients.
11:00
11:02:55 Join mendel_munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net)
11:03:08 Quit munkis (Ping timeout: 252 seconds)
11:03:10 Nick mendel_munkis is now known as munkis (~mendel_mu@ool-ae2cb218.dyn.optonline.net)
11:10:03rb-bluebotBuild Server message: Build round completed after 783 seconds.
11:10:05rb-bluebotBuild Server message: Revision 740a50687f result: All green
11:11:46sporkspeachy: the old dev builds page without all the voice files is a but more readable
11:21:17 Quit Ckat (Ping timeout: 268 seconds)
11:21:56 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g)
11:25:30 Quit munkis (Ping timeout: 240 seconds)
11:26:56 Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net)
11:41:42_bilgus g#3593 now has the other issues fixed it compiles but I havent tested it
11:41:45rb-bluebotGerrit review #3593 at https://gerrit.rockbox.org/r/c/rockbox/+/3593 : talk.c check for 0 talk clips file descriptor leaks & announce_status fix typo by William Wilgus
11:42:23_bilgusdesowin, thanks
11:45:32amachronicbilgus, do you remember the reason for this stack business in battery bench? g#2625
11:45:34rb-bluebotGerrit review #2625 at https://gerrit.rockbox.org/r/c/rockbox/+/2625 : Battery_Bench use plugin buffer for thread stack, stop scrolling by William Wilgus
11:46:01amachronici got a stkov battery bench after a while when I tried running it on the q1
11:46:29amachronicgonna try reverting back to the static stack because I found this huge stack created a weird problem on the debug screen
11:46:43amachronicbut i am guessing there is some other bug afoot too
11:48:03_bilguswanna say it was the fuze+ that was creating dumps that were ovfl the stack rather than keep increasing it I just made it take over the plugin buffer
11:51:10_bilgusthat plugin is TSR so its likely some weird context switch or a race
11:52:00_bilguswouldn't rule out others either, next thing would be is it just lasting too long and ovfl the run buffer?
11:52:16amachronicokay I'll have to figure out the cause it because stkov with a 2mb stack definitely can't happen.
11:52:54_bilgusIt probably needs logic to dump when the buffer is full IIRC it doesnt have that
11:53:36amachronicwhen i tried seeing the stack usage it caused audio to massively drop out
11:53:54amachronicit turns out we check stack usage by scanning the entire stack with IRQs disabled
11:54:07_bilgusthat might be because it uses a sentinel
11:54:37_bilgusfigure you are reading the whole buffer for the picket fence
11:54:44amachronicyeah
11:55:01amachronicthe usage is so small it shows up as 0% though so I doubt the stkov is genuine
11:55:20_bilgusso better idea is probably limit that to something reasonable with a max_stack too
11:58:23_bilgusmight also double check my logic here gThread.stack = (long *) buf + buf_size; /* stack grows towards *buf
11:58:37_bilgusL659
11:58:57_bilguswouldn't be the first time I assumed wrong on stack direction
12:00
12:02:11***Saving seen data "./dancer.seen"
12:04:02amachronicit's correct, the kernel wants the top of the stack / lowest address
12:04:39amachronicrandom aside: we're not aligning our stacks on MIPS to 8 bytes.
12:05:05 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
12:05:41amachronici wonder, does GCC follow the sysv ABI and could this cause any problpems?
12:05:43Telehubisamachronic: to be honest after few tries I think I also need to wait for jztool support for Q1 ;- )
12:07:03amachronicTelehubis: i've commited it but I haven't made builds or tested on windows yet
12:07:30_bilgusamachronic, I've run into a lot of alignment problems but usually its ARM
12:09:22Telehubisamachronic: sure. I just dont have exp. in Linux. Maybe its also bacause I run "Unix subsystem" dont know...
12:14:11amachronicstkov panic happens only if something writes to the very top of the stack
12:14:41amachronicso something must be written out of bounds right beyond the end of the plugin
12:17:59amachronichmm, it seems rockbox already has some gdb stub for ARM. Maybe I should add one for mips.
12:18:45amachronichas anybody used gdb stub in recent times or is it bitrotted / unreliable?
12:23:21_bilgusassume latter lol
12:23:57amachronicit got added 2006 and not touched since :(
12:24:32amachronicmaybe i can do a quick hack to dump pc when something touches that memory
12:24:39amachronic/
12:27:30braewoods_bilgus: question for you. i acquired a rare hd300 and there's no official battery but it does appear to be socketed. any ideas how i can find a compatible replacement, socket wise? i assume i'd need to take measurements of the socket or so
12:31:43_bilgusmight get lucky, ive made my own with various connectors even hand made copper ones used white kneed-able epoxy to encapsulate the connectors it even still plugs / unplug with proper prep/masking
12:32:54_bilgusother than that look through digikey or even EDA libraries thats how I found the pheonix connector spacing
12:33:58 Quit Telehubis (Quit: Connection closed)
12:33:59braewoodsi was thinking of using caliper
12:34:01braewoodscalipers
12:34:17braewoodsin any case for now it's a future problem
12:34:32braewoodsthe old battery looks like this, from the wiki
12:34:37braewoodshttps://www.rockbox.org/wiki/pub/Main/InsideMPIOHD300/7.jpg
12:35:07braewoodsit's a little weird in that it connects from the top not the side
12:35:44_bilgusproblem is w/o the original you don't know how the protect circuit works
12:35:49_bilgusassum an ntc
12:36:01braewoodsit has none afaik. it's just 2 pin.
12:36:09_bilgusif it works w/o it thats status quo it seems
12:36:48braewoodsvery slow charging right now
12:36:49_bilgusso you are just constrained by the l/w/h of the pack you can buy all day long
12:37:04braewoodsyea i'll look into it
12:37:18_bilgusI usually look through cell phone boxes
13:00
13:04:03 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:3109:34d3:47a1:1c02)
13:34:11braewoods_bilgus: what's the typical cut off voltage for rockbox targets? i've seen some lithium can go to around 3V but devices are free to cut out sooner
13:34:45braewoodsi assume they want to be > 3.3V so they can use a buck converter or so
13:34:58braewoodssince a lot of electronics use 3.3V internally
13:41:15 Quit amachronic (Quit: amachronic)
14:00
14:02:12***Saving seen data "./dancer.seen"
14:09:35 Join amachronic [0] (~amachroni@user/amachronic)
14:12:55amachronici think I found the reason for the stkov panic
14:13:37amachronicvarious bits of the core call plugin_get_buffer(), like the playlist viewer
14:14:27amachronici managed to reproduce reliably by running battery bench & then removing a song from the current playlist
14:23:12 Quit emacsomancer (Ping timeout: 268 seconds)
14:26:15 Join mendel_munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net)
14:26:29 Quit munkis (Remote host closed the connection)
14:35:37 Join emacsomancer [0] (~emacsoman@c-174-52-88-123.hsd1.ut.comcast.net)
14:37:22amachronicfixed battery bench: g#3597
14:37:24rb-bluebotGerrit review #3597 at https://gerrit.rockbox.org/r/c/rockbox/+/3597 : Fix battery_bench bug by using a static buffer for stack by Aidan MacDonald
14:38:19amachronicit looks like announce_status is the only other TSR plugin and it has the same problem, but it uses the plugin buffer for more than just stack
14:40:25amachronicthe only other way this could happen is if a function in the plugin API indirectly causes a double-allocation of the plugin buffer, but I haven't checked that yet.
14:41:21 Join yang [0] (~yang@user/yang)
15:00
15:01:26 Quit amachronic (Ping timeout: 268 seconds)
15:01:48 Quit emacsomancer (Ping timeout: 255 seconds)
15:31:50 Join emacsomancer [0] (~emacsoman@136.60.143.85)
15:37:01 Quit emacsomancer (Quit: WeeChat 3.2)
15:38:11 Join emacsomancer [0] (~emacsoman@136.60.143.85)
15:38:16braewoods_bilgus: at least i was able to find the dimensions by looking up the battery part #.
15:38:32braewoodsi'll see what i find later
15:38:44braewoodsfirst i want to confirm it still even powers on with the current battery
15:38:56braewoodsvery slow charging in any case
15:57:12 Quit emacsomancer (Ping timeout: 245 seconds)
15:57:40 Join amachronic [0] (~amachroni@user/amachronic)
16:00
16:02:15***Saving seen data "./dancer.seen"
16:10:42braewoodswell this is one weird player
16:10:49braewoodsi thought the input was busted
16:11:03braewoodsturns out, half of it pressure activated and the rest is touch
16:20:56_bilgusamachronic, oh that is not great..
16:21:20_bilgusthe plugin buffer is taken over even with that static buffer
16:21:49_bilgusit just so happens you aren't taking enough to hit the bug
16:22:08amachronicreally? how does that happen?
16:22:11braewoods_bilgus: what's the issue? a conflict between who owns the plugin buffer?
16:22:33braewoodsi thought the plugin buffer was off limits to anything other than plugins
16:22:59_bilguswell except in the case of those TSRs you wouldn't normally notice
16:23:36braewoodsand the benchmark is a background program?
16:23:52_bilgusI'll have to look but what can possibly happen is we could make get_plugin_buffer a bit smarter
16:24:06braewoodssounds like we need a way to move them to a dedicated memory region
16:24:15_bilgusyeah battery bench and my announce plugin are TSR
16:24:34braewoodswhy aren't they in rockbox core then? that would probably solve the issue
16:25:09braewoodsi was under the impression the plugins all exitted when they close
16:25:12braewoodsi guess not
16:25:17amachronicif it helps, i've converted announce_status to avoid the plugin buffer too
16:25:34amachronicbut if the plugin buffer is used anyway...
16:25:56_bilgusI'd rather get rid of those core uses of the plugin buffer and either make the users plugins or push them into core_alloc or some hybrid
16:26:01 Join emacsomancer [0] (~emacsoman@136.60.128.68)
16:26:28amachronicit should be safe as long as two threads don't use the plugin buffer at the same time
16:26:35_bilgusyeah plugins get copied into the plugin_buf then remaining is allowed for our use
16:26:46amachronicwhich we can detect by adding a 'free_plugin_buffer' API
16:27:01amachronicso if somebody tries to get_plugin_buffer before freeing it we panic
16:27:04braewoodswe need a real solution, not some hack for the handful of TSRs currently existing. what if we want to add more later?
16:27:13amachronicthis is not a TSR issue.
16:27:18braewoodsoh?
16:27:29amachronictsr just exposes it.
16:27:41_bilgus^
16:27:59braewoodsso what do we need? a way to shrink the plugin buffer area when a TSR is run?
16:28:00amachronicif a plugin API indirectly calls some function which uses the plugin buffer this could affect many more plugins.
16:28:13amachronicmalloc() ;)
16:28:20_bilguswell I think itd be ok just to mark it as in use
16:28:26braewoodsi could emulate malloc on top of core_alloc
16:28:34amachronicmore seriously I do not think we need malloc or change to core_alloc.
16:28:44braewoodsbut yea, more overhead
16:29:16 Quit emacsomancer (Read error: Connection reset by peer)
16:30:07_bilgusI'll have a look in core see just how much abuse we are talking but likely this has been happening for a long while we just get lucky
16:31:13amachronici'd assume most uses are safe since battery_bench and announce_tsatus bugs are recent changes
16:32:15_bilgusbat bench is old
16:32:25amachronic g#3599
16:32:27rb-bluebotGerrit review #3599 at https://gerrit.rockbox.org/r/c/rockbox/+/3599 : Fix announce_status usage of plugin buffer by Aidan MacDonald
16:33:00amachronicbat bench is old, but prior to your change it used a static stack so it was unaffected
16:33:10_bilguswon't hurt
16:33:33_bilgusno that static stack resides in the plugin buffer
16:33:55_bilgushave a loop at how load plugin works in plugin.c
16:33:58_bilguslook*
16:33:58amachronicyeah but get_plugin_buffer accounts for the size of the binary
16:34:15amachronicso if you use a static buffer it's skipped over and you get the unallocated part
16:34:28_bilgusshould when you call get_plugin_buffer as well I think
16:35:03_bilgusother thing might be someone abusing that alloc too
16:37:07_bilgusno you are indeed right it wouldn't store the state and it just returns the whole remaining
16:37:55 Join _amachronic [0] (~amachroni@user/amachronic)
16:39:03_bilgusso really there is no tracking of in use and it will continually return the remaining buffer
16:39:17_bilgusick
16:40:29 Quit amachronic (Read error: Connection reset by peer)
16:43:46_bilgusbraewoods, usually each target has a table for showing the battery remaining but charging setpoints are usually hardwired except a few targets where you can set them
16:44:27_bilgusthe clip+ and zip have several settings for trigger points and rate of charge IIRC
16:50:58 Quit lebellium (Quit: Leaving)
16:51:44 Quit reductum (Quit: WeeChat 2.8)
16:56:40 Quit mendel_munkis (Remote host closed the connection)
16:57:04 Join mendel_munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net)
17:00
17:16:55_amachronicTelehubis: q1 bootloader build is here: https://drive.google.com/drive/folders/1F4OhAVqKPcp879CykFCN5WL9ncYfPrvm
17:19:26_amachronicspeachy: ^^^ i've updated jztool and added the q1 bootloader, the m3k bootloader is unchanged. add those to d.r.o whenever you like, thanks.
17:24:45 Join emacsomancer [0] (~emacsoman@136.60.128.68)
17:40:40 Join speachy [0] (~speachy@209.2.65.77)
17:40:40 Quit speachy (Changing host)
17:40:40 Join speachy [0] (~speachy@rockbox/developer/speachy)
17:40:40Mode"#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat)
17:51:45 Quit _amachronic (Quit: _amachronic)
17:52:45 Quit emacsomancer (Quit: WeeChat 3.2)
17:53:50 Join emacsomancer [0] (~emacsoman@136.60.128.68)
18:00
18:02:19***Saving seen data "./dancer.seen"
18:12:57 Join reductum [0] (~reductum@2603-8000-b400-8764-dea6-32ff-fe16-a622.res6.spectrum.com)
18:35:05 Join cockroach [0] (~blattodea@user/cockroach)
18:54:38 Quit cockroach (Ping timeout: 255 seconds)
18:54:52 Join cockroach [0] (~blattodea@user/cockroach)
19:00
19:19:25 Join Riviera [0] (Riviera@user/riviera)
19:24:41braewoods_bilgus: in any case, i'm going to have to replace it now. i broke the old ones terminals. lol
19:25:01braewoodswhile i'm at it i may as well see if i can reliably trigger the failsafe
19:25:14rb-bluebotBuild Server message: New build round started. Revision 966e210e6d, 303 builds, 8 clients.
19:25:22braewoodsi want to investigate the possibility of releasing an updated bootloader
19:25:56braewoodscoldfire ports all have a failsafe that boots the OF
19:26:04braewoodsbut it can be tricky to trigger it
19:32:34 Quit ZincAlloy (Quit: Leaving.)
19:36:17rb-bluebotBuild Server message: Build round completed after 663 seconds.
19:36:19rb-bluebotBuild Server message: Revision 966e210e6d result: All green
19:36:22rb-bluebotBuild Server message: New build round started. Revision b91ad60d63, 303 builds, 7 clients.
19:36:29 Quit cockroach (Quit: leaving)
19:36:49 Join cockroach [0] (~blattodea@user/cockroach)
19:49:05rb-bluebotBuild Server message: Build round completed after 763 seconds.
19:49:07rb-bluebotBuild Server message: Revision b91ad60d63 result: All green
20:00
20:02:21***Saving seen data "./dancer.seen"
20:48:46 Join dconrad [0] (~dconrad@208.38.228.17)
21:00
21:15:53 Quit Piece_Maker (Ping timeout: 258 seconds)
21:17:29 Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net)
22:00
22:02:23***Saving seen data "./dancer.seen"
22:26:24 Quit cockroach (Quit: leaving)
22:41:22speachyI'm re-running the analyzer using the X3ii's sim build; it'll pull in the full set of (simmable) plugins and have full color, which ought to flag many more issues.
22:51:19speachyhttps://www.shaftnet.org/~pizza/scan-build-223915
23:00
23:12:52braewoodswow. i'd have never guessed reading bits was this slow.
23:25:10 Quit Airwave (Quit: WeeChat 2.3)
23:33:00 Quit mendel_munkis (Ping timeout: 255 seconds)
23:54:43 Quit dconrad (Remote host closed the connection)

Previous day | Next day