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-06-28

00:01:00 Quit sadjhflj333 (Ping timeout: 265 seconds)
00:56:38desowin__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:11desowinalso 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__builtindesowin: of course, but how does it work?
02:10:22__builtinah, just a sentinel pattern?
02:12:05__builtinI believe we have something of that nature already
02:12:36__builtinbut I've never looked closely at how it works
02:12:58__builtinand it clearly doesn't work very well...
02:25:32__builtindesowin: in fact, it seems like we already have that in place
02:25:49__builtinsee switch_thread() in firmware/kernel/thread.c
02:29:45__builtinnow I'm curious why that didn't trigger on this bug
02:30:48__builtinthe check looks for 0xdeadbeef in the lowest 4 bytes of the stack being switched _away_ from
02:35:31__builtinso 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__builtinI'm inclined to believe the latter
02:37:18 Join desowin [0] (
02:47:04__builtinI'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__builtinperhaps 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:32MarcAndersenI finally found a enableplugins flag that I could turn off and then the sim built fine.
03:53:37braewoodsdesowin: 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] (
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@
04:54:24 Join markun [0] (
05:02:21***Saving seen data "./dancer.seen"
05:41:40 Quit asaba (Quit: Relay server offline)
05:41:54 Join asaba [0] (~asabas@
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] (
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] (
08:41:03 Join massiveH [0] (
09:02:29***Saving seen data "./dancer.seen"
09:12:46 Join dfkt [0] (
09:15:06 Quit dfkt (Client Quit)
09:15:13 Join dfkt [0] (
09:17:50 Quit dfkt (Client Quit)
10:02:53desowin-braewoods: I don't know what you mean by adjacent allocations
10:03:44desowin-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:01desowin-or by checking if the saved stack pointer on switch out is within stack range
10:04:17braewoodsdesowin-: e.g. stack variables of the same function allocated right next to each other; no spacing
10:04:36desowin-the stack pointer check won't catch transient overflows
10:04:48braewoodsso mainly out of control ones
10:04:57braewoodsnot off by one or similar ones
10:05:26braewoodsi thought as much. i've used malloced buffers to test for that before.
10:05:50braewoodsvalgrind 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:03desowin-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] (
11:52:09 Join p3tur [0] (
11:54:44 Quit p3tur (Client Quit)
11:56:46 Quit petur (Ping timeout: 272 seconds)
12:32:33 Join speachy [0] (~speachy@
12:32:33Mode"#rockbox +v speachy" by ChanServ (
12:33:16speachy__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:26speachyand of course it won't help you if you overwrite legit data elsewhere..
12:52:52braewoodsor do OOB reads
13:02:34***Saving seen data "./dancer.seen"
13:17:52__builtinspeachy: yeah, that checks with my understanding of the source
13:18:37speachyshort of making the guard reigon much larger proprotionally there's not much we can really do.
13:19:01__builtinI think what must have been happening in my case was that some function allocated a large array on the stack
13:19:37__builtinwhich was never written to in its entirety, thus "skipping over" the guard region
13:19:43speachyyep, that's typical
13:21:47__builtinwe might want to look into some sort of optional "enhanced stkov checking"
13:22:11__builtinand enable it only when debugging
13:24:14speachywe 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__builtinwe can also check the stack pointer of yielding threqds against the lower bound of the stack
13:42:38__builtinbut that wouldn't catch transient overflows...
13:49:33 Quit akaWolf (Ping timeout: 268 seconds)
13:49:40 Join akaWolf [0] (
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] (
19:02:40***Saving seen data "./dancer.seen"
19:14:15MarcAndersenWhat does it mean that my 10 character build number ends with a capital m?
19:34:31braewoodsMarcAndersen: 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] (
19:57:47 Quit __builtin (Ping timeout: 244 seconds)
20:01:25 Join Natch [0] (
21:02:41***Saving seen data "./dancer.seen"
21:14:17MarcAndersenI am having trouble building the manual. My current problem is a missing inputenx.sty. Any thoughts?
21:16:01 Join __builtin [0] (~quassel@
21:16:26__builtin[21:15:34] <ffffff__builtin> MarcAnderson: the M means it's a dirty tree iirc
21:16:53__builtinbraewoods: it's actually the git commit and date code
21:18:07MarcAndersenThanks. 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] (
21:43:18 Quit michaelni (Ping timeout: 250 seconds)
21:50:57 Join michaelni [0] (
23:02:43***Saving seen data "./dancer.seen"
23:37:46 Join Bobathan [0] (

Previous day | Next day