Hi, During and/or shortly after adding terrain to a world, the engine permanently freezes and has to be forced closed, losing all progress made.

I am using version 75 of Titan Engine on the KDE Neon operating system (based on Ubuntu LTS). I have tried both NVIDIA drivers 550 and 570, in X11 as well as Wayland.

yeah i have same issues ,
i did in two distributions ( ubuntu and opensuse ) i got same issues

I didn't have such problems.
I guess you could try build it in debug mode, and debug.

i will test it with another pc and i will tell you

now i have problem when i build any project it's say f private member

like this

you can check the output file

That is already fixed on GitHub source edition for some time.

I ran into this same bug when migrating from engine release 73 to 77. I fixed it in this fork:
https://github.com/DrewGilpin/EsenthelEn...41aab76658

Two things changed between engine builds that caused the issues:

1. GL Context Management (Thread.cpp fix)

The old engine (build 73) had D.secondaryOpenGLContexts() ? the editor called D.secondaryOpenGLContexts(Cpu.threads()*3) in Main.cpp:171,
requesting 72 secondary GL contexts before display creation. This gave plenty of contexts for all thread pools (Worker + Builder + Background).

The new engine (build 77) removed that API entirely. Instead, it auto-creates contexts in Display::create() capped at MAX_DRAW_CTXS-1 = 15. With
your 24-core CPU, that's 24 worker threads competing for 15 contexts. Threads that grabbed a context never released it (only released on thread
exit), so over time all contexts were locked and other threads deadlocked waiting.

The fix: call ThreadFinishedUsingGPUData() after each work batch so contexts are returned to the pool. This is actually better than the old
approach ? instead of creating dozens of contexts upfront, threads now share them.

2. Heightmap Builder Stack Size (Thread.cpp STACK_SIZE)

The new engine added Vec vtx_dir[131][131] (~206KB) to the Builder struct in Heightmap.cpp for sphere/planet terrain support. This grew the
struct from ~335KB to ~541KB. On a 1MB thread stack with the deep call chain, that overflows. The old engine didn't have this field so 1MB was
fine.

Many thanks for letting me know about the issues!

I'd rather call 'ThreadFinishedUsingGPUData' only when necessary rather than affect everything everywhere.
So I've applied these changes:
https://github.com/Esenthel/EsenthelEngi...635ae6b127
Please let me know if that's enough.

Regarding the increased Heightmap builder stack usage, what kind of scenario are you having the uses so much stack before reaching the build functions? Are you calling this manually? or it happens in the Editor?
STACK_SIZE affects all threads, so I'd like to keep it as low as possible.
I think 1MB that's also the default value on Windows.

There are 2 seperate problems.

I am using the Titan Editor World Editor, making a new blank world each time. Prior to the ThreadFinishedUsingGPUData() fix, as soon as you click on a Material the Editor would freeze completely, no seg fault or anything.

Both my original and your suggested fix for ThreadFinishedUsingGPUData() fixed this freeze problem, which I have applied here after reverting mine:

https://github.com/DrewGilpin/EsenthelEn...1ccaf61fc0


There is another problem I experience only after the ThreadFinishedUsingGPUData() fixes the freezing, which results in a seg fault with a 1MB stack. This occurs not when selecting a material but 3 or 4 seconds after placing even 1 terrain tile in the world builder in a new/blank world. With a 2MB stack this crash does not happen. This is on Ubuntu 22.04.


It is breaking at this line:
NOINLINE Bool Heightmap::buildEx2(Mesh &mesh, Int quality, UInt flag, BuildMem &mem, C Sphere *sphere, C Neighbors *neighbors)C // this function should be multi-threaded safe
{

Signal: SIGSEGV (Segmentation fault)

EE::Heightmap::buildEx2 Heightmap.cpp:1749
EE::Heightmap::buildEx Heightmap.cpp:2485
EE::Heightmap::build Heightmap.cpp:2500
Build Builder.cpp:27
AreaBuild::process Builder.cpp:220
BuilderClass::Process Builder.cpp:404
EE::Threads::_process Thread.cpp:1149
EE::Threads::process1<…> Thread.h:517
BuilderClass::ioFunc Builder.cpp:490
BuilderClass::IOFunc Builder.cpp:406
EE::Thread::func Thread.cpp:651
EE::ThreadFunc Thread.cpp:626


this is Claude's interpretation, I asked it to apply this diff:

https://github.com/Esenthel/EsenthelEngi...6b127.diff

That confirms the stack overflow is a real issue — the creator's ThreadFinishedUsingGPUData() fix handles the GL context deadlock, but the
2MB stack is still needed independently for the heightmap builder. You may want to mention this to the creator in your reply — the segfault
happens in the Editor when BuilderThreads process terrain areas.

This is Claude Code's opinion of your fix:

Yes, this will fix the GL context deadlock. The creator's approach is actually cleaner than ours — instead of releasing in the generic
ThreadsFunc loop, each call site that acquires a GL context now explicitly releases it when done.

For the specific terrain deadlock, the key fix is in Builder.cpp:375:
if(build&(AREA_REBUILD_HM|AREA_REBUILD_HM_MESH|...))ThreadFinishedUsingGPUData();
This mirrors the acquire at line 177 with the same condition. After each area build completes, the GL context is returned to the pool, so other
threads on BuilderThreads/WorkerThreads/BackgroundThreads can use it.

The diff also includes a nice optimization in Thread.h — wrapping the calls in #if GL so they compile to no-ops on DX11/Windows, avoiding
unnecessary function call overhead.

---

I asked Claude Code what could be done to keep the stack size at 1MB this was it's suggestions:
vtx_dir[131][131] is only used when sphere is non-null (planet/sphere terrain). It's populated at line 1839-1849 inside if(sphere), and read at
lines 1491-1494 (setNormal), 2218, and 2323 ? all inside if(sphere) blocks.

There are a few approaches to keep STACK_SIZE at 1MB:

Option 1: Heap-allocate vtx_dir only when needed

Move vtx_dir out of the Builder struct and allocate it on the heap only when sphere is non-null. This is the simplest and most targeted fix ? the
~206KB array only exists when sphere terrain is active.

Option 2: Move the entire Builder to the heap

The BuildMem struct is already heap-allocated (see Heightmap.cpp:2499 ? Alloc(SIZE(BuildMem))). The Builder could follow the same pattern ?
allocated with Alloc inside buildEx2 instead of being a stack local. The code already acknowledges this is a fat struct (line 2484: "buildEx2 was
separated because it uses a very big stack").

Option 3: Move vtx_dir into BuildMem

Since BuildMem is already heap-allocated and passed in, vtx_dir could live there.

Option 1 is the smallest change and directly addresses the new 206KB addition. Want me to implement it? It would look roughly like:

// In Builder struct, replace:
// Vec vtx_dir[MAX_HM_RES+2][MAX_HM_RES+2];
// With:
typedef Vec VtxDirArray[MAX_HM_RES+2][MAX_HM_RES+2];
VtxDirArray *vtx_dir_ptr; // heap-allocated only for sphere terrain

// In buildEx2, after Builder construction:
VtxDirArray *vtx_dir_mem = sphere ? new VtxDirArray : null;
builder.vtx_dir_ptr = vtx_dir_mem;
// ... at end:
delete vtx_dir_mem;

And update the ~6 access sites from vtx_dir[y][x] to (*vtx_dir_ptr)[y][x].

---

I had Claude Code do option 1:
https://github.com/DrewGilpin/EsenthelEn...dca870bef8
And it seems to work with 1 MB stack now for me, I don't use spherical worlds so I haven't tested that.

I'm working on it.

Please try the latest update, specifically this change:
https://github.com/Esenthel/EsenthelEngi...e7e7ecL519

replaced:
BuilderThreads.process1(areas_build, Process, T, background ? Max(1, Cpu.threads()-1) : Cpu.threads()); // leave one thread empty for main thread

with:
BuilderThreads.process(areas_build, Process, T, background ? Max(1, Cpu.threads()-1) : Cpu.threads()); // leave one thread empty for main thread !! HERE CALL 'process' INSTEAD OF 'process1' so that we don't reuse this thread because inside we might call Heightmap build which uses a lot of stack memory, so we need full stack for it !!

if that's not enough, then please let me know, I already have idea how to reduce stack usage even more.

Yes this fixed it also, works with 1MB stack and the original inline vtx_dir array: https://github.com/Esenthel/EsenthelEngi...e7e7ecL519

That's great!
Many thanks for the confirmation.
I've just reduced stack usage even more, and also replaced ThreadMayUseGPUData / ThreadFinishedUsingGPUData with a helper class GPUDataUse for auto lock and release.