I’m using sweeprolog as my daily driver, kudos @oskardrums for writing it! I love the features, but I’m experiencing some instability with top-level commands. For example, when running sweeprolog-restart, my emacs crashes - particularly disruptive as it simultaneously closes all of my open docs, prolog-related or not.
For clarity: I’m on (doom) emacs 29.1 operating as a daemon. Anyone else experiencing this?
Thanks, if you have a core dump or some kind of trace from the crash, that’d be ideal. Otherwise, just the basics about your setup might help: which versions of SWI-Prolog, Emacs, and Sweep you are using, and maybe how you’ve installed them.
P.S. small tip: the command M-x sweeprolog-submit-bug-report creates a bug report buffer prepopulated with some of the commonly relevant data points.
I check the logs via journalctl --user -u emacs.service but nothing of substance is logged there. That said, when the “crash” happens, the entire content of the *messages* buffer is wiped out, which leads me to think that the crash is happening but maybe is being restarted without printing anything?
I’m not entirely sure the issue is confined to cases when Emacs is running as a daemon, because I remember seeing a crash during PL_cleanup (which sweeprolog-restart calls), and I rarely run Emacs as a daemon. Does this crash reproduce for you with Emacs running as a daemon?
It might be a good idea to update to the latest version (0.26.0), there were some changes around how Emacs communicates with top-level threads which may be relevant if you’re restarting Sweep while there are top-levels running.
I might have been a little unclear before, when I use the daemon, this crash is not something that happens randomly, but a deterministic behavior. The PL_cleanup seem promising, how can I try to activate it manually to see if it crashes?
Cleanup and restart Prolog in the same process is not well supported by various of the extension packages that use C code. Many such packages tend to store things that are constant in a Prolog session. They should implement an uninstall handler to clear these cached handles, but they don’t. Also, the order in which things would need to be shut down cleanly is not always clear.
So, unfortunately, restarting should be considered unsafe when extensions are involved and quite likely there are still bugs without extensions. That makes sweep not very usable with emacs server mode It is more like using the built-in editor: you get a Prolog process with an editor. This may crash, in particular when not well tested foreign extensions are involved. When working in such scenarios, I tend to have two. One I use for editing with the code loaded such that all nice features work and one I use for testing and debugging.
I’ve also had Emacs crash when trying to restart the top-level, generally after a bunch of stuff has been loaded, including packages with C code (particularly my automake pack). I’ve just been working around this by using a separate terminal window to actually run my code, but obviously being able to live fully in Emacs would be superior…
At some point I’ll try to track this down, but we have a brand-new baby in the home now, so my time is rather limited and fragmented
Thanks for the clarification, I’ve looked a bit into it and I suspect this has to do with our recent transition to using a pty for the communication between Emacs and the top-level thread. This seems to run into troubles when Emacs is running as a daemon, although I’m not sure exactly why just yet.
Could you please try setting sweeprolog-top-level-use-pty to nil before starting any top-levels (maybe in your init file) and check if you still see this crash?
I’ve now pushed an update that addresses this issue. @meditans you should be able to set sweeprolog-top-level-use-pty back to t without fear of the Emacs daemon shutting down when you close a top-level