Newest at the top
| 2025-07-28 18:58:03 +0200 | DoNald | (~aa@110.137.36.197) |
| 2025-07-28 18:51:09 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Ping timeout: 272 seconds) |
| 2025-07-28 18:50:58 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 240 seconds) |
| 2025-07-28 18:50:54 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-07-28 18:50:01 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) |
| 2025-07-28 18:49:47 +0200 | trickard | (~trickard@cpe-51-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-07-28 18:37:24 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-28 18:31:15 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-07-28 18:25:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-07-28 18:21:32 +0200 | trickard_ | trickard |
| 2025-07-28 18:21:19 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) LainIwakura |
| 2025-07-28 18:15:57 +0200 | ycp | (~znc@user/dragestil) dragestil |
| 2025-07-28 18:15:38 +0200 | ycp | (~znc@user/dragestil) (Server closed connection) |
| 2025-07-28 18:15:03 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Ping timeout: 272 seconds) |
| 2025-07-28 18:07:53 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) LainIwakura |
| 2025-07-28 18:01:15 +0200 | guest10 | (~guest10@nrwh-12-b2-v4wan-167917-cust3575.vm23.cable.virginm.net) (Quit: Client closed) |
| 2025-07-28 17:57:39 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) |
| 2025-07-28 17:57:26 +0200 | trickard | (~trickard@cpe-51-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-07-28 17:56:01 +0200 | guest10 | (~guest10@nrwh-12-b2-v4wan-167917-cust3575.vm23.cable.virginm.net) |
| 2025-07-28 17:51:28 +0200 | hseg | (~gesh@46.120.20.122) (Ping timeout: 240 seconds) |
| 2025-07-28 17:47:38 +0200 | ndudaev | (~ndudaev@83.29.118.149.ipv4.supernova.orange.pl) (Ping timeout: 272 seconds) |
| 2025-07-28 17:45:03 +0200 | trickard_ | trickard |
| 2025-07-28 17:43:31 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) |
| 2025-07-28 17:43:18 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-07-28 17:41:37 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-07-28 17:37:41 +0200 | AVA | (~AVA@84.54.80.216) (Read error: Connection reset by peer) |
| 2025-07-28 17:28:31 +0200 | <Henson> | merijn: yes |
| 2025-07-28 17:28:13 +0200 | <merijn> | ok, so you do specifically need malloc :) |
| 2025-07-28 17:28:05 +0200 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-07-28 17:27:48 +0200 | <Henson> | merijn: the problem with that is that in my production code I don't know a-priori the amount of memory that should be allocated, because it's being allocated in the C/C++ layer and passed back to Haskell. |
| 2025-07-28 17:26:43 +0200 | <merijn> | https://hackage.haskell.org/package/base-4.21.0.0/docs/Foreign-ForeignPtr.html#v:mallocForeignPtrB… |
| 2025-07-28 17:26:40 +0200 | <merijn> | I've always used Foreign.ForeignPtr, so I was guessing that's why I'm used to seeing it in profiles while you might not |
| 2025-07-28 17:25:51 +0200 | <merijn> | Since it uses GHC's newAlignedPinnedByteArray, rather than malloc |
| 2025-07-28 17:25:16 +0200 | <merijn> | Henson: I meant more like, using mallocForeignPtrBytes, which allocates using GHC's allocator and SHOULD appear in memory profiles |
| 2025-07-28 17:24:41 +0200 | <Henson> | merijn: the problem also happens with C++ "new" and "delete" |
| 2025-07-28 17:24:13 +0200 | trickard_ | (~trickard@cpe-51-98-47-163.wireline.com.au) |
| 2025-07-28 17:24:11 +0200 | <merijn> | Henson: Do you specifically need C malloc or just any allocation? |
| 2025-07-28 17:23:58 +0200 | <Henson> | merijn: oh, also, the leak when using "async" will not happen with "+RTS -N1" |
| 2025-07-28 17:23:43 +0200 | trickard | (~trickard@cpe-51-98-47-163.wireline.com.au) (Ping timeout: 245 seconds) |
| 2025-07-28 17:23:34 +0200 | <merijn> | (not your leak problem, the profiling one) |
| 2025-07-28 17:23:23 +0200 | <merijn> | The problem is calloc :) |
| 2025-07-28 17:23:17 +0200 | <merijn> | Henson: Ah, wait |
| 2025-07-28 17:22:40 +0200 | <Henson> | merijn: I don't think it does. I've done every kind of memory profiling the GHC's profiling offers, and the C-based memory allocation doesn't show up. |
| 2025-07-28 17:22:40 +0200 | sam113102 | sam113101 |
| 2025-07-28 17:22:36 +0200 | sam113101 | (~sam@modemcable200.189-202-24.mc.videotron.ca) (Read error: Connection reset by peer) |
| 2025-07-28 17:22:33 +0200 | sam113102 | (~sam@modemcable200.189-202-24.mc.videotron.ca) sam113101 |
| 2025-07-28 17:21:03 +0200 | <merijn> | I would expect that to still show up as a PINNED allocation |
| 2025-07-28 17:21:03 +0200 | <Henson> | merijn, magic_rb: I'm working on putting together a minimal reproducer. |
| 2025-07-28 17:20:15 +0200 | <Henson> | merijn: I have tried profiling, but the problem is that the calloc returns a pointer, which is tiny, but points to a large amount of memory. Because the memory is allocated in the C level, the RTS isn't able to keep track of it, so no significant memory usage shows up. |
| 2025-07-28 17:19:21 +0200 | <merijn> | That said, this is hard to troubleshoot without a minimal reproducer like magic_rb said |