Using r9065 I undid the change to the DEC_COUNT_NULL macro in basic.cpp. Then, using the attached files I created a website with Tools->Create website. No crash.
I've also tried to crash TeXmacs with the procedure reported in

but haven't succeeded. A cursory scan of the log reveals that since this thread was started many changes have been made to the Qt code, including usage of QPointers for QActions, several leaks fixed, wrapping of some raw pointers and better deletion of objects.

I don't have the time to "bisect" the history to find out which commit fixed it, but it seems like this particular problem at least is solved. I will test further and report back again in a while.

The idea to set the rep field to NULL may temporarily hide the bug, but I doubt that it constitutes a genuine fix. We really need to understand what is going on. The change in the DEC_ macro also is not harmless to the execution speed and size of the produced binary.

Ok, that previous comment ends up with some garbled stuff from previous versions (this tracker sucks...)

I meant to say that a quick and harmless (?) fix is to set the rep field to NULL in the DEC_* macros in basic.cpp. This is done in commit 8043 and fixes the previous problem. Now I really am unable to crash TeXmacs opening and closing buffers and windows.

Sadly, there are still ways to crash texmacs which are related to this bug:

Open TeXmacs.

Open new window.

Create new buffer in window 2.

Close the new buffer.

Click the close button of window 2.

Dead.

The crash happens during deletion of QTMWidget, triggered by the deletion of the qt_window_widget inside kill_window(): QTMWidget's smartpointer to its owning qt_simple_widget_rep goes out of scope and tries to delete (again) this object. Either

we are directly deleting some editor_rep* somewhere before,

or we have a copy of the simple_widget_rep* (is this possible?)

or ?

A "solution" is to set the rep field to NULL after tm_delete() in the macros DEC_COUNT_NULL. I think this can do no harm, so

during execution of qt delayed commands in qt_gui. Some have a qt_simple_widget_rep* as payload in their blackboxes which has already been deleted by the time the command

There's a fix for the crash in commit 7972: QWidgets were being deleted once manually and again via the layout (note: QLayout::removeWidget() does NOT alter ownership, one has to takeAt(), delete the widget and the QLayoutItem for that.)

However, "synchronization errors" still happen (quite) sporadically and are caught by the Pokemon catcher. I have seen no instability afterwards.

Create a directory with two non trivial TeXmacs documents. Next convert the directory to Html using Tools -> Web -> Create web site. In the Qt version, this causes TeXmacs to crash. It seems that the crash is due to a change in revision 5549. I investigated a bit, but even the new exception handling mechanism is not able to catch this bug. So it seems that something is seriously out of sync at the Qt side.