Newest at the top
| 2025-07-28 17:00:46 +0200 | trickard_ | trickard |
| 2025-07-28 16:55:58 +0200 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-07-28 16:55:53 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Ping timeout: 272 seconds) |
| 2025-07-28 16:48:25 +0200 | AVA | (~AVA@84.54.80.216) |
| 2025-07-28 16:40:31 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: irc.renjuan.org (juan@acm.org)) |
| 2025-07-28 16:38:08 +0200 | <merijn> | So if you're holding on to async's the threads don't get GCed and (in turn) nothing in that thread's GC root will be |
| 2025-07-28 16:37:41 +0200 | <merijn> | Async contains a ThreadId and threads are not GCed while you hold on to their threadid |
| 2025-07-28 16:35:58 +0200 | <merijn> | Since async's doc even have a warning about using withAsync, since async might leak |
| 2025-07-28 16:35:40 +0200 | <merijn> | Wild guess is that the async is never cleaned up, keeping the pointer alive indefinitely |
| 2025-07-28 16:34:34 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) |
| 2025-07-28 16:31:27 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) (Ping timeout: 252 seconds) |
| 2025-07-28 16:12:20 +0200 | thaumavorio | (~thaumavor@thaumavor.io) thaumavorio |
| 2025-07-28 16:11:35 +0200 | thaumavorio | (~thaumavor@thaumavor.io) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-07-28 16:08:14 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) |
| 2025-07-28 16:08:00 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-07-28 16:00:20 +0200 | <haskellbridge> | <magic_rb> A minimal reproducer would be great |
| 2025-07-28 16:00:05 +0200 | <haskellbridge> | <magic_rb> Maybe the ptrs are being held alive by something? |
| 2025-07-28 15:56:02 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 248 seconds) |
| 2025-07-28 15:51:42 +0200 | zlqrvx | (~zlqrvx@101.175.150.247) (Quit: ZNC 1.10.0 - https://znc.in) |
| 2025-07-28 15:48:01 +0200 | ndudaev | (~ndudaev@83.29.118.149.ipv4.supernova.orange.pl) |
| 2025-07-28 15:43:47 +0200 | <Henson> | I've tried many different RTS tuning parameters releated to garbage collection but nothing seems to help. The memory seems to be un-deallocatable. Even I called "performGC" often it doesn't make any difference. Pausing the threads doesn't make a difference. The memory seems like it can't be released properly and never gets cleaned up. |
| 2025-07-28 15:43:41 +0200 | <Lycurgus> | *at all |
| 2025-07-28 15:43:13 +0200 | <Lycurgus> | looks like CSE was just a typo, not a design pattern at al, but someone had computer science education on mind |
| 2025-07-28 15:42:27 +0200 | <Henson> | they're spawned with "asyncBound" then it doesn't happen. If instead of wrapping the Ptrs into ForeignPtrs I just pass the Ptrs from the allocator to deallocator thread, then the memory leak doesn't happen either. I'm trying to understand why the leak happens with the ForeignPtr + async combination. |
| 2025-07-28 15:41:29 +0200 | <Henson> | hi everyone, I'm encountering a problem with foreign memory allocation and haskell-based threading using "async". If I allocate memory on one thread using callocBytes and pass that to another thread that deallocates it, I encounter a memory leak. When the Ptr is bundled into an ForeignPtr and the allocator/deallocator threads are spawned with "async" then the memory leak happens. But if... |
| 2025-07-28 15:38:14 +0200 | Henson | (~kvirc@192-0-202-2.cpe.teksavvy.com) Henson |
| 2025-07-28 15:36:58 +0200 | Square2 | (~Square@user/square) (Ping timeout: 240 seconds) |
| 2025-07-28 15:20:44 +0200 | ndudaev2 | (~ndudaev@213.17.133.9) (Ping timeout: 260 seconds) |
| 2025-07-28 15:18:25 +0200 | ndudaev | (~ndudaev@user/ndudaev) (Ping timeout: 244 seconds) |
| 2025-07-28 15:17:44 +0200 | yin | (~zero@user/zero) zero |
| 2025-07-28 15:16:25 +0200 | ndudaev2 | (~ndudaev@213.17.133.9) |
| 2025-07-28 15:15:15 +0200 | yin | (~zero@user/zero) (Remote host closed the connection) |
| 2025-07-28 15:11:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-28 15:11:29 +0200 | myme | (~myme@2a01:799:d5e:5f00:6e9c:287:57c3:f10c) myme |
| 2025-07-28 15:10:58 +0200 | haritz | (~hrtz@user/haritz) haritz |
| 2025-07-28 15:10:58 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
| 2025-07-28 15:10:58 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
| 2025-07-28 15:10:49 +0200 | myme | (~myme@2a01:799:d5e:5f00:7f02:95a9:7b47:a0d4) (Ping timeout: 260 seconds) |
| 2025-07-28 15:10:14 +0200 | akegalj | (~akegalj@95.168.120.48) (Ping timeout: 260 seconds) |
| 2025-07-28 15:09:15 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) |
| 2025-07-28 15:09:10 +0200 | <fp> | Looking at the conversation from yesterday, what is a CSE in the package/environment management context? I can't seem to get anything out of an internet search |
| 2025-07-28 15:09:01 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-07-28 15:06:20 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) LainIwakura |
| 2025-07-28 14:59:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-28 14:58:06 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-07-28 14:55:23 +0200 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-07-28 14:54:11 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) |
| 2025-07-28 14:54:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-28 14:53:43 +0200 | trickard | (~trickard@cpe-51-98-47-163.wireline.com.au) (Ping timeout: 245 seconds) |
| 2025-07-28 14:53:42 +0200 | stef204 | (~stef204@user/stef204) stef204 |