Threadscope crashes

[idontgetoutmuch]

Dominics-MacBook-Pro:Private dom$ threadscope 

(threadscope:22060): Gtk-WARNING **: Attempting to store changes into `/Users/dom/.local/share/recently-used.xbel', but failed: Failed to create file '/Users/dom/.local/share/recently-used.xbel.R2H7VX': No such file or directory

(threadscope:22060): Gtk-WARNING **: Attempting to set the permissions of `/Users/dom/.local/share/recently-used.xbel', but failed: No such file or directory
threadscope: user error (out of memory)

threadscope 0.2.6

ls -ltr ~/ESandbox.eventlog 
-rw-r--r--@ 1 dom  staff  102892260 Mar 27 14:47 /Users/dom/ESandbox.eventlog

With larger event logs this happened when zooming in. With this actual event log it happens when I try to export a png.

[Mikolaj]

Thank you for the report. How much memory did it actually consume before crashing?

This commit message reminds me TS was tested with large eventlogs:

Mikolaj/eventlogs@c394a66

but I don't remember if I also tested exporting a png with them or not. In any case, your eventlog may be denser than these in some respects (e.g., generated with different GHC options) or perhaps TS became more memory hungry since that time. In case anybody tries to debug the problem, is it possible to regenerate any of your example eventlogs easily?

[idontgetoutmuch]

Hard to say how much it consumed before crashing. It was consuming over 2G before I zoomed in and it crashed with "out of memory". I can't supply the code that is generating the problem. I can supply the actual log if that helps.

[Mikolaj]

Yep, if that's not a problem, that would be very helpful for whomever ventures to fix the memory usage (volunteers are very welcome; debugging Haskell is fun (comparatively, anyway:)).

[idontgetoutmuch]

It seems to be a problem on my macbook only. On an ubuntu machine it works albeit taking up well over 3G. It also took about 30 seconds to load a 100M log.

I am going to close this; I suspect it will forever remain one of life's great unsolved mysteries.

[seanparsons]

I've just had this issue on an eventlog that isn't even a single megabyte in size.

This looks to be exactly the same as #50 as well.