--- Log for 28.06.121 Server: tantalum.libera.chat Channel: #rockbox --- Nick: rb-logbot_ Version: Dancer V4.16 Started: 18 hours and 59 minutes ago 00.01.00 Quit sadjhflj333 (Ping timeout: 265 seconds) 00.22.48 # yes 00.56.38 # __builtin: should we get stack overflow detection? FreeRTOS stack detection method 2 has catched virtually all stack overflows I have got, so we could get something similar 01.00.11 # also stack watermarking is quite useful 01.02.19 *** Saving seen data "./dancer.seen" 01.30.25 Quit jadzia (Remote host closed the connection) 02.08.31 # <__builtin> desowin: of course, but how does it work? 02.10.22 # <__builtin> ah, just a sentinel pattern? 02.10.52 # <__builtin> (https://www.freertos.org/Stacks-and-stack-overflow-checking.html) 02.12.05 # <__builtin> I believe we have something of that nature already 02.12.36 # <__builtin> but I've never looked closely at how it works 02.12.58 # <__builtin> and it clearly doesn't work very well... 02.25.32 # <__builtin> desowin: in fact, it seems like we already have that in place 02.25.49 # <__builtin> see switch_thread() in firmware/kernel/thread.c 02.29.45 # <__builtin> now I'm curious why that didn't trigger on this bug 02.30.48 # <__builtin> the check looks for 0xdeadbeef in the lowest 4 bytes of the stack being switched _away_ from 02.35.31 # <__builtin> so either the check never ran in the first place (unlikely, since the thread with the bug should yield shortly after overflowing its stack 02.36.06 Quit desowin (Read error: Connection reset by peer) 02.36.14 # <__builtin> ... or, the offending code skipped past the sentinel value (which is only 4 bytes long) 02.36.21 # <__builtin> I'm inclined to believe the latter 02.37.18 Join desowin [0] (~linux@078088109026.wroclaw.vectranet.pl) 02.47.04 # <__builtin> I'm really curious why the stkov checker doesn't seem to work in this case, even if I have it check a much larger region 02.47.43 # <__builtin> perhaps my offending code has a large stack-allocated buffer that happens to be where the sentinel is? 03.02.20 *** Saving seen data "./dancer.seen" 03.47.32 # I finally found a enableplugins flag that I could turn off and then the sim built fine. 03.53.37 # desowin: IIRC, don't stack overflow checkers share one common drawback? they can't detect overflows between adjacent allocations? i've only seen them detect it when they went well beyond that 03.57.20 Join desowin- [0] (~linux@078088109026.wroclaw.vectranet.pl) 03.57.49 Quit desowin (Read error: Connection reset by peer) 04.02.36 Quit markun (Ping timeout: 258 seconds) 04.08.58 Join petur [0] (~petur@199.59.5.111) 04.54.24 Join markun [0] (~markun@178-84-100-63.dynamic.upc.nl) 05.02.21 *** Saving seen data "./dancer.seen" 05.41.40 Quit asaba (Quit: Relay server offline) 05.41.54 Join asaba [0] (~asabas@103.113.159.184) 06.50.07 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:893f:b1d4:aa1e:e5c3) 07.00.05 Quit akaWolf (Ping timeout: 268 seconds) 07.00.13 Join akaWolf [0] (~akaWolf@akawolf.org) 07.02.25 *** Saving seen data "./dancer.seen" 07.48.41 Quit lebellium (Quit: Leaving) 08.23.21 Quit rogeliodh (Ping timeout: 272 seconds) 08.26.26 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) 08.41.03 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.02.29 *** Saving seen data "./dancer.seen" 09.12.46 Join dfkt [0] (~dr0ne@84-115-229-245.cable.dynamic.surfer.at) 09.15.06 Quit dfkt (Client Quit) 09.15.13 Join dfkt [0] (~dfkt@84-115-229-245.cable.dynamic.surfer.at) 09.17.50 Quit dfkt (Client Quit) 10.02.53 # braewoods: I don't know what you mean by adjacent allocations 10.03.44 # the one in Rockbox basically checks if the bottom 4 bytes were overwritten, it could be improved by extending this (at the cost of more memory usage) 10.04.01 # or by checking if the saved stack pointer on switch out is within stack range 10.04.17 # desowin-: e.g. stack variables of the same function allocated right next to each other; no spacing 10.04.36 # the stack pointer check won't catch transient overflows 10.04.48 # so mainly out of control ones 10.04.57 # not off by one or similar ones 10.05.26 # i thought as much. i've used malloced buffers to test for that before. 10.05.50 # valgrind can easily see when you're OOB on one of those 10.12.28 Quit massiveH (Quit: Leaving) 11.02.32 *** Saving seen data "./dancer.seen" 11.11.03 # valgrind utilizes memory protection features so it can do much more than is possible with just sentinels 11.22.47 Quit akaWolf (Ping timeout: 268 seconds) 11.47.05 Join akaWolf [0] (~akaWolf@akawolf.org) 11.52.09 Join p3tur [0] (~petur@78-21-55-218.access.telenet.be) 11.54.44 Quit p3tur (Client Quit) 11.56.46 Quit petur (Ping timeout: 272 seconds) 12.32.33 Join speachy [0] (~speachy@209.2.65.77) 12.32.33 Mode "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) 12.33.16 # __builtin: wrt the stov detection; IIRC we only check to see if the final sentinel is valid, but it only catches stuff we actually write to 12.35.26 # and of course it won't help you if you overwrite legit data elsewhere.. 12.52.52 # or do OOB reads 13.02.34 *** Saving seen data "./dancer.seen" 13.17.52 # <__builtin> speachy: yeah, that checks with my understanding of the source 13.18.37 # short of making the guard reigon much larger proprotionally there's not much we can really do. 13.19.01 # <__builtin> I think what must have been happening in my case was that some function allocated a large array on the stack 13.19.37 # <__builtin> which was never written to in its entirety, thus "skipping over" the guard region 13.19.43 # yep, that's typical 13.21.47 # <__builtin> we might want to look into some sort of optional "enhanced stkov checking" 13.22.11 # <__builtin> and enable it only when debugging 13.24.14 # we could also enable the compiler's static stack size checks, but they're a bit of a blunt instrument given our differing stack sizes. 13.42.04 # <__builtin> we can also check the stack pointer of yielding threqds against the lower bound of the stack 13.42.38 # <__builtin> but that wouldn't catch transient overflows... 13.49.33 Quit akaWolf (Ping timeout: 268 seconds) 13.49.40 Join akaWolf [0] (~akaWolf@akawolf.org) 15.02.37 *** Saving seen data "./dancer.seen" 17.02.38 *** No seen item changed, no save performed. 17.29.36 Join cockroach [0] (~blattodea@user/cockroach) 18.54.46 Quit akaWolf (Ping timeout: 272 seconds) 18.57.14 Join akaWolf [0] (~akaWolf@akawolf.org) 19.02.40 *** Saving seen data "./dancer.seen" 19.14.15 # What does it mean that my 10 character build number ends with a capital m? 19.34.31 # MarcAndersen: no idea, i thought it was randomly generated or tied to some other binary number of no special significance 19.35.34 Quit Galois (Ping timeout: 244 seconds) 19.56.45 Quit dys (Ping timeout: 244 seconds) 19.57.16 Quit Natch (Ping timeout: 244 seconds) 19.57.16 Quit CasBot1 (Ping timeout: 244 seconds) 19.57.25 Join CasBot1 [0] (~matrixirc@connolly.tech) 19.57.47 Quit __builtin (Ping timeout: 244 seconds) 20.01.25 Join Natch [0] (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se) 21.02.41 *** Saving seen data "./dancer.seen" 21.14.17 # I am having trouble building the manual. My current problem is a missing inputenx.sty. Any thoughts? 21.16.01 Join __builtin [0] (~quassel@204.48.30.120) 21.16.26 # <__builtin> [21:15:34] <ffffff__builtin> MarcAnderson: the M means it's a dirty tree iirc 21.16.53 # <__builtin> braewoods: it's actually the git commit and date code 21.18.07 # Thanks. I'm currently trying to reinstall texlive. The original one I had was the 2020 ubuntu version, now I am trying with the official 2021. 21.31.36 Quit cockroach (Quit: leaving) 21.32.26 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 21.43.18 Quit michaelni (Ping timeout: 250 seconds) 21.50.57 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 23.02.43 *** Saving seen data "./dancer.seen" 23.37.46 Join Bobathan [0] (~admin@cpe-65-29-248-157.wi.res.rr.com)