Newest at the top
| 2024-10-15 21:19:08 +0200 | <tomsmeding> | Henson: all second digits are even, in released versions, so 9.7 is not going to exist :p |
| 2024-10-15 21:18:50 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) machinedgod |
| 2024-10-15 21:16:21 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds) |
| 2024-10-15 21:16:06 +0200 | synchromesh | (~john@2406:5a00:2497:300:3d3b:a134:d9b5:8c99) synchromesh |
| 2024-10-15 21:15:09 +0200 | synchromesh | (~john@2406:5a00:2497:300:acce:5ad8:3e10:a59d) (Read error: Connection reset by peer) |
| 2024-10-15 21:14:31 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-10-15 21:13:30 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-10-15 21:12:47 +0200 | euleritian | (~euleritia@84.19.220.82) |
| 2024-10-15 21:12:22 +0200 | euleritian | (~euleritia@dynamic-176-003-036-091.176.3.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-10-15 21:09:17 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-10-15 21:09:07 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-15 21:08:44 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-10-15 21:06:16 +0200 | briandaed | (~root@185.234.210.211.r.toneticgroup.pl) (Remote host closed the connection) |
| 2024-10-15 21:00:36 +0200 | caconym | (~caconym@user/caconym) caconym |
| 2024-10-15 21:00:23 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-10-15 21:00:18 +0200 | <Henson> | sm: thank you for your suggestion. I did try a slightly newer version of GHC (9.7.something) I think, and the problem still persisted. Trying a much newer version is difficult. |
| 2024-10-15 21:00:00 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-10-15 20:59:57 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Client Quit) |
| 2024-10-15 20:59:20 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-10-15 20:59:08 +0200 | <Henson> | work a try -> worth a try |
| 2024-10-15 20:59:01 +0200 | <Henson> | tomsmeding: well it's work a try. Unfortunately that doesn't seem to be the problem. There aren't a lot of them being created, only 74. And 3 of those are network descriptors that haven't changed. |
| 2024-10-15 20:57:07 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Client Quit) |
| 2024-10-15 20:57:07 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-10-15 20:55:28 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-15 20:55:12 +0200 | <tomsmeding> | (I have no idea what could be the cause, just suggesting a possible source of additional clues) |
| 2024-10-15 20:54:53 +0200 | <Henson> | ahh yes, that would be helpful |
| 2024-10-15 20:54:39 +0200 | <tomsmeding> | i.e. are the sockets properly closed |
| 2024-10-15 20:54:34 +0200 | <tomsmeding> | Henson: perhaps something else to try: if you lsof your process (e.g. in htop with the 'l' key, but also plain lsof works), do you get a leak of file descriptors too? |
| 2024-10-15 20:54:05 +0200 | ljdarj1 | ljdarj |
| 2024-10-15 20:54:05 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2024-10-15 20:53:36 +0200 | <tomsmeding> | yes, what sm said |
| 2024-10-15 20:53:27 +0200 | <tomsmeding> | oof, okay |
| 2024-10-15 20:53:13 +0200 | <Henson> | tomsmeding: for a long time. The program's designed to run for days. In a stripped-down version of the program intended to elicit just the memory leak, it takes a couple minutes to clear the low bar of 2 GB that I've set for it. With no network access it'll sit around 800 MB for an hour. |
| 2024-10-15 20:51:54 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-15 20:51:41 +0200 | <tomsmeding> | the GC cleans up memory, perhaps it simply didn't run yet? |
| 2024-10-15 20:51:28 +0200 | <tomsmeding> | Henson: how long are you running that program? |
| 2024-10-15 20:51:22 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) raehik |
| 2024-10-15 20:49:34 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-10-15 20:44:44 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-15 20:39:41 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-15 20:28:39 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-10-15 20:25:15 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-10-15 20:23:53 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-15 20:21:26 +0200 | <haskellbridge> | <sm> #ghc or the GHC release notes might know more |
| 2024-10-15 20:21:04 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-10-15 20:20:55 +0200 | <haskellbridge> | <sm> I expect this is hard, but if you could compare more modern GHC and libraries that would be useful info |
| 2024-10-15 20:20:31 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-10-15 20:13:00 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-15 20:09:44 +0200 | euphores | (~SASL_euph@user/euphores) euphores |
| 2024-10-15 20:08:10 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |