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 2023-01-01

00:01:57 Join Trzyzet_ [0] (
00:02:59 Quit Trzyzet (Ping timeout: 260 seconds)
00:02:59 Nick Trzyzet_ is now known as Trzyzet (
00:06:49***Saving seen data "./dancer.seen"
00:10:53speachy__builtin: yeah there's a PHP8.1 issue with flyspray. happens only when there are URLs in the message
00:11:15speachyhappy new year, y'all...
00:47:34 Quit massiveH (Quit: Leaving)
00:54:31 Join massiveH [0] (~massiveH@2600:4040:a992:a300:a912:be81:e9a3:52ff)
01:14:38 Join Schimon [0] (
01:43:58 Join chris_s [0] (
01:45:54chris_shappy new year! g4982 indeed fixes Boomshine being unresponsive on iPods
01:46:42 Quit chris_s (Client Quit)
02:06:50***Saving seen data "./dancer.seen"
03:22:27 Quit massiveH (Quit: Leaving)
03:56:10 Quit pixelma (Quit: .)
03:56:10 Quit amiconn (Quit: - Chat comfortably. Anywhere.)
03:57:12 Join pixelma [0] (
03:57:13 Join amiconn [0] (
04:06:51***Saving seen data "./dancer.seen"
06:06:54***No seen item changed, no save performed.
06:49:34 Join CH23 [0] (~CH23@revspace/participant/ch23)
07:05:54 Quit CH23_M (Read error: Connection reset by peer)
07:06:15 Join CH23_M [0] (~CH23@revspace/participant/ch23)
08:06:55***Saving seen data "./dancer.seen"
09:46:18speachy_bilgus: looks like one bit of red in the build from the keyremap context
09:47:03_bilgusthe ClipV2? or something new?
09:47:04speachychris_s: I'll bet there are more threading bugs lurking. at least in code that wasn't designed to be thread-safe.
09:47:22speachyyeah, clipv2. seems kinda random but... eh
09:47:24_bilgusapparently the clipV2 has a physical hold switch
09:47:38_bilgusI don't remember this being the case but meh
09:48:11_bilgusbeen easily 15 years since Ive used a clip v1/v2
09:49:18_bilgusreally I questioned several years ago how many were still in the wild I bet that number is very few by now especially
09:52:57_bilgusthere is something afoot in tlsf on the sim but I haven't found it yet, looking at alignment atm as I got an error 'struct bhdr_t', requires 8 byte alignment
09:55:27_bilgusvoid* x 2 is 16 here so maybe thats the issue but I can't see how
09:56:10speachythe tlsf code auto-aligns to 2*void* but x86_64 doesn't care about unaligned pointers
09:57:33_bilgusmight be asan being overly agressive but probably not
10:06:56***No seen item changed, no save performed.
10:09:52_bilgusI get SEGV on Read in free() in the other sgt games too so its not just lua
10:10:01_bilguslua just calls free a lot
12:06:59***No seen item changed, no save performed.
12:11:51 Join fourHZ90 [0] (
12:14:08 Quit fourHZ (Ping timeout: 260 seconds)
12:19:09 Nick fourHZ90 is now known as fourHZ (
12:37:41_bilgusso i've narrowed tlsf down to the free block coalesce it appears to happen when a value 0xnn0 gets allocated on free it is rounded to 0xnn2 then | FREE_BLOCK makes it 0xnn3 when I rounded the specific failing free it moved on to failing at the next matching pattern
12:47:40speachyis it not allocating a long enough block?
13:03:29 Quit CH23_M (Ping timeout: 260 seconds)
13:04:08 Join CH23_M [0] (~CH23@revspace/participant/ch23)
13:08:49_bilgusnot sure yet
13:21:58 Quit CH23_M (Read error: Connection reset by peer)
13:22:28 Join CH23_M [0] (~CH23@revspace/participant/ch23)
13:23:32_bilgusits the previous block hdr pointing to a bad address the bits at the end denote PREV_FREE but i'm just seeing the end result still need to tack it back further
13:33:48speachycould it be corrupted by the caller going out of bounds?
13:40:04_bilguswell the caller asks for a size that either succeeds or fails and they get a pointer then they call free later on that pointer I guess the caller could corrupt the pointer?
13:40:31speachyyeah, if the caller doesn't pass in the same pointer to free() all bets are off.
13:40:35_bilgusbut it doesn't appear to be plus amachronic said plain old malloc worked
13:40:44speachyor the caller could over/underrun the allocated block
13:41:47_bilgusthat could be I guess I can make the blocks bigger and check a sentinel
13:42:12_bilgusif my fence posts are mowed down
14:04:21_bilguslooks like the pointers all come back intact
14:04:57_bilgusI suppose that was likely considering the sgts puzzles are unlikely to be overwriting as well
14:07:01_bilgusbasically I doubled the size and filled with a a sentinel and put a second marker at the end of the expected alloc it comes back intact but is tlsf overwriting it I guess is the next question
14:07:04***Saving seen data "./dancer.seen"
15:53:21_bilgusspeachy see g#4984 this is as much as I could implement before running into the issue
15:53:24rb-bluebotGerrit review #4984 at : [Experiment] tlsf working by William Wilgus
16:07:07***No seen item changed, no save performed.
16:09:23_bilgusthis area catches my eye
16:49:00speachyis it possible this is still due to multithreading? even putting aside multiple CPU stuff, the tlsf code is not threadsafe unless built with locking.
16:51:00_bilgusI can try building it with locking but I can't imagine so
16:51:18_bilgusI think the sanity check is overwriting something
16:51:39_bilgusthats the last part missing between the two and thats where it all goes sideways
16:52:49_bilguslocking does no bueno
17:31:42 Quit lebellium (Quit: Leaving)
18:07:08***Saving seen data "./dancer.seen"
19:18:06 Join massiveH [0] (~massiveH@2600:4040:a992:a300:a912:be81:e9a3:52ff)
19:39:41 Join CH230 [0] (~CH23@revspace/participant/ch23)
19:41:19 Quit CH23_M (Ping timeout: 260 seconds)
19:42:11 Quit CH23 (Ping timeout: 264 seconds)
19:51:09 Join CH23_M [0] (~CH23@revspace/participant/ch23)
20:00:05 Quit CH23_M (Read error: Connection reset by peer)
20:00:05 Quit CH230 (Read error: Connection reset by peer)
20:01:39 Join CH230 [0] (~CH23@revspace/participant/ch23)
20:03:47 Join CH23_M [0] (~CH23@revspace/participant/ch23)
20:07:12***Saving seen data "./dancer.seen"
20:07:52 Nick CH230 is now known as CH23 (~CH23@revspace/participant/ch23)
20:14:48 Quit Nezumi-sama (Ping timeout: 268 seconds)
20:16:21 Join Nezumi-sama [0] (
20:58:05 Quit JanC (Remote host closed the connection)
20:58:24 Join JanC [0] (~janc@user/janc)
21:26:40 Join dconrad [0] (~dconrad@
21:48:19 Quit dconrad ()
22:07:15***Saving seen data "./dancer.seen"
22:41:46 Nick launchd is now known as l (launchd@bitbot/launchd)
23:21:14 Quit Schimon (Ping timeout: 260 seconds)
23:37:11 Quit m01 (Quit: Konversation terminated.)
23:38:01 Join Schimon [0] (
23:39:00saanaitoDoes anyone here know of any sub-$100 PAPs with USB-C for charging+data? Rockbox-able or not
23:39:22 Join m01 [0] (
23:39:48saanaito(I'd probably have an easier time modding my Clip Zip, but I'm curious anyway)
23:49:09 Quit Piece_Maker (Quit: ZNC 1.8.2 -
23:49:43 Join Piece_Maker [0] (
23:54:07_bilgusI'd recommend not modding your clipzip its got some of the tiniest pads i've ever seen in an electronic device someone just bought a (Surfans F20?) that has usb c but I don't know that we support it
23:54:42_bilgusspeachy it turns out its the pointer tagging
23:55:05_bilgusand even doing it through a struct asan still has a fit
23:56:26_bilgusrather a union sorry
23:57:59_bilgus^ it strips the bits back off here

Previous day | Next day