--- Log for 20.07.121 Server: molybdenum.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 5 days and 22 hours ago 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.12.28 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:49c1:bcff:9db4:f4aa) 02.01.59 *** Saving seen data "./dancer.seen" 02.04.21 Quit lebellium (Quit: Leaving) 02.27.31 # Coverity Scan reported 915 issues, to view click add me to project at https://scan.coverity.com/projects/rockbox 02.32.10 # sorting 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.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.58 # https://www.youtube.com/watch?v=HJDY1FXuJPQ some Rockbox love on Youtube 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.02.05 *** Saving seen data "./dancer.seen" 06.09.00 Quit ufdm (Read error: Connection reset by peer) 06.52.24 # _bilgus: no, because when path is null pathsize is 0, so the memcpy() does nothing. 06.54.02 # Going to the URL you mentioned it claims no builds were succsssfully analyzed.. don't have a way of looking at that report. 07.03.04 # (didn't get an invite email either, FWIW) 07.03.16 # desowin: ^^ 07.10.32 # but if the most severe issue is a fd leak, then we're doing better than I'd expected. 07.33.31 # (a leak in a called-once-at-startup error path!) 07.37.55 # there are a bunch of out of bounds accesses... 07.39.29 # I suspect such a bug is behind what I'm debugging 07.39.55 # I 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.25 # if you study computer science, check if your faculty has one 07.42.33 # when I was student, there was Ellisys USB Explorer 200 that I could access 07.42.40 # I will when I go back there, I finished up my work for this year and I'm with my parents rn 07.43.13 # there'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.25 # there's a bunch of USB 2.0 LeCroy Conquest units on ebay right now, but they're still $500ish. 07.50.36 # OpenVizsla is probably the cheapest, with fairly good Wireshark support (of course, my opinion is biased as I wrote the dissector and ovextcap) 07.51.47 # for students, university equipment would be most affordable 07.53.44 # Back 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.06 # A 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.04 # I was disappointed that their attempt to crowdfund a USB3.0 version of it failed miserably... 07.58.48 # We (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.40 # huh, did not know that 08.02.08 *** Saving seen data "./dancer.seen" 08.06.16 # I have an openvizla board here; if I can get it to work I'll donate it to the rockbox cause. 08.07.32 # is the ftdi programmed with OpenVizsla VID/PID or defaults? 08.08.04 # because well, if it's programmed then it is trivial to get it running nowadays 08.08.27 # (if not, then it's not a big deal unless there are still some soldering issues) 08.09.20 # I think it's the latter, actually. that's why I got it for so cheap. 08.09.49 # quick way to tell is to plug it and check how it enumerates (if at all) 08.09.49 # I didn't have the time to debug it at the time but I still have it (and a second bare PCB) 08.10.32 # when my colleague at work assembled one manually, the FTDI and RAM chips had to be resoldered 08.10.41 # doesn't appear to enumerate at all. 08.10.59 # (got it five years ago, so..) 08.11.19 # suprisingly the USB transceiver got soldered correctly first try 08.12.38 # silly question, but you plug it with the connector on the side where there's just one connector (to capture host)? 08.13.28 # yes. the second time. :D 08.14.10 # could 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.05 # I'll take it into the lab at work and try to probe the FTDI chip during any downtime 08.16.29 # aaand 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.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.05 # I 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.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.13 # Telehubis: 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.40 # amachronic: 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.38 # if 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.57 # Build Server message: 3New build round started. Revision 6f042e91dd, 303 builds, 8 clients. 10.40.12 # Telehubis: 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.19 # I can give you a bootloader later today -- I'm happy to release it as-is, just let me merge g#3589 first 10.42.21 # 3Gerrit review #3589 at https://gerrit.rockbox.org/r/c/rockbox/+/3589 : 3jztool: add support for Shanling Q1 and Eros Q by Aidan MacDonald 10.42.58 # amachronic: thanks! 10.43.42 # is there any easy way to tell which build a builder last participated in? 10.45.17 # Build Server message: 3Build round completed after 740 seconds. 10.45.19 # Build Server message: 3Revision 6f042e91dd result: All green 10.45.34 # just noticed that uzziyah isn't building and am trying to figureout why. 10.56.59 # Build Server message: 3New build round started. Revision 740a50687f, 303 builds, 8 clients. 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.03 # Build Server message: 3Build round completed after 783 seconds. 11.10.05 # Build Server message: 3Revision 740a50687f result: All green 11.11.46 # speachy: 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.45 # 3Gerrit review #3593 at https://gerrit.rockbox.org/r/c/rockbox/+/3593 : 3talk.c check for 0 talk clips file descriptor leaks & announce_status fix typo by William Wilgus 11.42.23 # <_bilgus> desowin, thanks 11.45.32 # bilgus, do you remember the reason for this stack business in battery bench? g#2625 11.45.34 # 3Gerrit review #2625 at https://gerrit.rockbox.org/r/c/rockbox/+/2625 : 3Battery_Bench use plugin buffer for thread stack, stop scrolling by William Wilgus 11.46.01 # i got a stkov battery bench after a while when I tried running it on the q1 11.46.29 # gonna try reverting back to the static stack because I found this huge stack created a weird problem on the debug screen 11.46.43 # but i am guessing there is some other bug afoot too 11.48.03 # <_bilgus> wanna 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 # <_bilgus> that plugin is TSR so its likely some weird context switch or a race 11.52.00 # <_bilgus> wouldn't rule out others either, next thing would be is it just lasting too long and ovfl the run buffer? 11.52.16 # okay I'll have to figure out the cause it because stkov with a 2mb stack definitely can't happen. 11.52.54 # <_bilgus> It probably needs logic to dump when the buffer is full IIRC it doesnt have that 11.53.36 # when i tried seeing the stack usage it caused audio to massively drop out 11.53.54 # it turns out we check stack usage by scanning the entire stack with IRQs disabled 11.54.07 # <_bilgus> that might be because it uses a sentinel 11.54.37 # <_bilgus> figure you are reading the whole buffer for the picket fence 11.54.44 # yeah 11.55.01 # the usage is so small it shows up as 0% though so I doubt the stkov is genuine 11.55.20 # <_bilgus> so better idea is probably limit that to something reasonable with a max_stack too 11.58.23 # <_bilgus> might also double check my logic here gThread.stack = (long *) buf + buf_size; /* stack grows towards *buf 11.58.37 # <_bilgus> L659 11.58.57 # <_bilgus> wouldn't be the first time I assumed wrong on stack direction 12.02.11 *** Saving seen data "./dancer.seen" 12.04.02 # it's correct, the kernel wants the top of the stack / lowest address 12.04.39 # random 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.41 # i wonder, does GCC follow the sysv ABI and could this cause any problpems? 12.05.43 # amachronic: to be honest after few tries I think I also need to wait for jztool support for Q1 ;- ) 12.07.03 # Telehubis: i've commited it but I haven't made builds or tested on windows yet 12.07.30 # <_bilgus> amachronic, I've run into a lot of alignment problems but usually its ARM 12.09.22 # amachronic: sure. I just dont have exp. in Linux. Maybe its also bacause I run "Unix subsystem" dont know... 12.14.11 # stkov panic happens only if something writes to the very top of the stack 12.14.41 # so something must be written out of bounds right beyond the end of the plugin 12.17.59 # hmm, it seems rockbox already has some gdb stub for ARM. Maybe I should add one for mips. 12.18.45 # has anybody used gdb stub in recent times or is it bitrotted / unreliable? 12.23.21 # <_bilgus> assume latter lol 12.23.57 # it got added 2006 and not touched since :( 12.24.32 # maybe i can do a quick hack to dump pc when something touches that memory 12.24.39 # / 12.27.30 # _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 # <_bilgus> might 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 # <_bilgus> other 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.59 # i was thinking of using caliper 12.34.01 # calipers 12.34.17 # in any case for now it's a future problem 12.34.32 # the old battery looks like this, from the wiki 12.34.37 # https://www.rockbox.org/wiki/pub/Main/InsideMPIOHD300/7.jpg 12.35.07 # it's a little weird in that it connects from the top not the side 12.35.44 # <_bilgus> problem is w/o the original you don't know how the protect circuit works 12.35.49 # <_bilgus> assum an ntc 12.36.01 # it has none afaik. it's just 2 pin. 12.36.09 # <_bilgus> if it works w/o it thats status quo it seems 12.36.48 # very slow charging right now 12.36.49 # <_bilgus> so you are just constrained by the l/w/h of the pack you can buy all day long 12.37.04 # yea i'll look into it 12.37.18 # <_bilgus> I usually look through cell phone boxes 13.04.03 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:3109:34d3:47a1:1c02) 13.34.11 # _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.45 # i assume they want to be > 3.3V so they can use a buck converter or so 13.34.58 # since a lot of electronics use 3.3V internally 13.41.15 Quit amachronic (Quit: amachronic) 14.02.12 *** Saving seen data "./dancer.seen" 14.09.35 Join amachronic [0] (~amachroni@user/amachronic) 14.12.55 # i think I found the reason for the stkov panic 14.13.37 # various bits of the core call plugin_get_buffer(), like the playlist viewer 14.14.27 # i 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.22 # fixed battery bench: g#3597 14.37.24 # 3Gerrit review #3597 at https://gerrit.rockbox.org/r/c/rockbox/+/3597 : 3Fix battery_bench bug by using a static buffer for stack by Aidan MacDonald 14.38.19 # it 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.25 # the 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.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.16 # _bilgus: at least i was able to find the dimensions by looking up the battery part #. 15.38.32 # i'll see what i find later 15.38.44 # first i want to confirm it still even powers on with the current battery 15.38.56 # very slow charging in any case 15.57.12 Quit emacsomancer (Ping timeout: 245 seconds) 15.57.40 Join amachronic [0] (~amachroni@user/amachronic) 16.02.15 *** Saving seen data "./dancer.seen" 16.10.42 # well this is one weird player 16.10.49 # i thought the input was busted 16.11.03 # turns out, half of it pressure activated and the rest is touch 16.20.56 # <_bilgus> amachronic, oh that is not great.. 16.21.20 # <_bilgus> the plugin buffer is taken over even with that static buffer 16.21.49 # <_bilgus> it just so happens you aren't taking enough to hit the bug 16.22.08 # really? how does that happen? 16.22.11 # _bilgus: what's the issue? a conflict between who owns the plugin buffer? 16.22.33 # i thought the plugin buffer was off limits to anything other than plugins 16.22.59 # <_bilgus> well except in the case of those TSRs you wouldn't normally notice 16.23.36 # and the benchmark is a background program? 16.23.52 # <_bilgus> I'll have to look but what can possibly happen is we could make get_plugin_buffer a bit smarter 16.24.06 # sounds like we need a way to move them to a dedicated memory region 16.24.15 # <_bilgus> yeah battery bench and my announce plugin are TSR 16.24.34 # why aren't they in rockbox core then? that would probably solve the issue 16.25.09 # i was under the impression the plugins all exitted when they close 16.25.12 # i guess not 16.25.17 # if it helps, i've converted announce_status to avoid the plugin buffer too 16.25.34 # but if the plugin buffer is used anyway... 16.25.56 # <_bilgus> I'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.28 # it should be safe as long as two threads don't use the plugin buffer at the same time 16.26.35 # <_bilgus> yeah plugins get copied into the plugin_buf then remaining is allowed for our use 16.26.46 # which we can detect by adding a 'free_plugin_buffer' API 16.27.01 # so if somebody tries to get_plugin_buffer before freeing it we panic 16.27.04 # we need a real solution, not some hack for the handful of TSRs currently existing. what if we want to add more later? 16.27.13 # this is not a TSR issue. 16.27.18 # oh? 16.27.29 # tsr just exposes it. 16.27.41 # <_bilgus> ^ 16.27.59 # so what do we need? a way to shrink the plugin buffer area when a TSR is run? 16.28.00 # if a plugin API indirectly calls some function which uses the plugin buffer this could affect many more plugins. 16.28.13 # malloc() ;) 16.28.20 # <_bilgus> well I think itd be ok just to mark it as in use 16.28.26 # i could emulate malloc on top of core_alloc 16.28.34 # more seriously I do not think we need malloc or change to core_alloc. 16.28.44 # but yea, more overhead 16.29.16 Quit emacsomancer (Read error: Connection reset by peer) 16.30.07 # <_bilgus> I'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.13 # i'd assume most uses are safe since battery_bench and announce_tsatus bugs are recent changes 16.32.15 # <_bilgus> bat bench is old 16.32.25 # g#3599 16.32.27 # 3Gerrit review #3599 at https://gerrit.rockbox.org/r/c/rockbox/+/3599 : 3Fix announce_status usage of plugin buffer by Aidan MacDonald 16.33.00 # bat bench is old, but prior to your change it used a static stack so it was unaffected 16.33.10 # <_bilgus> won't hurt 16.33.33 # <_bilgus> no that static stack resides in the plugin buffer 16.33.55 # <_bilgus> have a loop at how load plugin works in plugin.c 16.33.58 # <_bilgus> look* 16.33.58 # yeah but get_plugin_buffer accounts for the size of the binary 16.34.15 # so if you use a static buffer it's skipped over and you get the unallocated part 16.34.28 # <_bilgus> should when you call get_plugin_buffer as well I think 16.35.03 # <_bilgus> other thing might be someone abusing that alloc too 16.37.07 # <_bilgus> no 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 # <_bilgus> so really there is no tracking of in use and it will continually return the remaining buffer 16.39.17 # <_bilgus> ick 16.40.29 Quit amachronic (Read error: Connection reset by peer) 16.43.46 # <_bilgus> braewoods, 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 # <_bilgus> the 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.16.55 # <_amachronic> Telehubis: q1 bootloader build is here: https://drive.google.com/drive/folders/1F4OhAVqKPcp879CykFCN5WL9ncYfPrvm 17.19.26 # <_amachronic> speachy: ^^^ 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.40 Mode "#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.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.19.25 Join Riviera [0] (Riviera@user/riviera) 19.24.41 # _bilgus: in any case, i'm going to have to replace it now. i broke the old ones terminals. lol 19.25.01 # while i'm at it i may as well see if i can reliably trigger the failsafe 19.25.14 # Build Server message: 3New build round started. Revision 966e210e6d, 303 builds, 8 clients. 19.25.22 # i want to investigate the possibility of releasing an updated bootloader 19.25.56 # coldfire ports all have a failsafe that boots the OF 19.26.04 # but it can be tricky to trigger it 19.32.34 Quit ZincAlloy (Quit: Leaving.) 19.36.17 # Build Server message: 3Build round completed after 663 seconds. 19.36.19 # Build Server message: 3Revision 966e210e6d result: All green 19.36.22 # Build Server message: 3New 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.05 # Build Server message: 3Build round completed after 763 seconds. 19.49.07 # Build Server message: 3Revision b91ad60d63 result: All green 20.02.21 *** Saving seen data "./dancer.seen" 20.48.46 Join dconrad [0] (~dconrad@208.38.228.17) 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.02.23 *** Saving seen data "./dancer.seen" 22.26.24 Quit cockroach (Quit: leaving) 22.41.22 # I'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.19 # https://www.shaftnet.org/~pizza/scan-build-223915 23.12.52 # wow. 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)