Randy, I'll be interested to hear if this permanently fixes the problem. I'm still having random crash on quit errors on 4D Server (16.3HF4, 64-bit). Never a problem in version 15, 32-bit. I have never connected crashing to a status interface, but in my case it has always run in a separate process. I just made a change to ensure that process is dead before QUIT 4D is called on the server. Maybe that will completely solve it.
Did you look at the backtrace from the crash log? I would be interested to see if we are experiencing the same issue. Below is what I see. I wonder if that is related to displaying the countdown timer - I'm quitting with QUIT 4D(60). Thread 46 Crashed:: QUIT_SERVER (id = -11) 0 4d.com.Map Server.app 0x0000000108e88fbc V4DClientProcessManager::Clear(bool) + 128 1 4d.com.Map Server.app 0x0000000108e8c1eb V4DServer::Unpublish() + 87 2 4d.com.Map Server.app 0x0000000108e8d1e6 V4DServer::_Shutdown(xbox::VTime&, xbox::VString const*, xbox::VString const*, VDatabaseStartupParameters*, xbox::VUUID const*) + 38 3 4d.com.Map Server.app 0x0000000108e8d300 V4DServer::Shutdown(int, xbox::VString const*, xbox::VString const*, VDatabaseStartupParameters*, xbox::VUUID const*) + 120 4 4d.com.Map Server.app 0x000000010915a636 do_quit4d(runtime4dLink*) + 123 5 4d.com.Map Server.app 0x0000000108ce5028 VDBLanguageContext::ExecuteCommand(runtime4dLink*) + 62 6 4d.com.Map Server.app 0x0000000108cd9530 VDBLanguageContext_compiled::ExecuteRuntimeCommand(int, int, champvar_template<256>**) + 94 7 4d.com.Map Server.app 0x0000000108afeff1 rt_CallRuntime4D2 + 45 8 ??? 0x000000010e364a43 0 + 4533406275 9 4d.com.Map Server.app 0x000000010907fbcb CallAsmPart2 + 65 10 ??? 0x000070000051e6e0 0 + 123145307678432 11 4d.com.Map Server.app 0x0000000108cd9354 VDBLanguageContext_compiled::DoExecute(calcblock&, VCodeDescriptor*) + 164 12 4d.com.Map Server.app 0x0000000108ce3e18 VDBLanguageContext::Execute(VDB4DTableProxy*, VFormContext*, short, int, int, champvar_template<256>**, VCodeDescriptor*) + 162 13 4d.com.Map Server.app 0x0000000108ce3a92 VDBLanguageContext::ExecuteProjectMethod(VMethodInfo const*, int, champvar_template<256>**, VDB4DTableProxy*, VFormContext*, short, int) + 542 14 4d.com.Map Server.app 0x0000000108cbd08c V4DWorkerMessage::_Execute(VDBLanguageContext*, VFormContext*) + 110 15 4d.com.Map Server.app 0x0000000108cbd850 V4DWorker::Run(V4DTaskConcrete*) + 208 16 4d.com.Map Server.app 0x0000000108e97da4 Task4DStoredMethodProc(V4DTaskConcrete*, xbox::IRefCountable*) + 222 17 4d.com.Map Server.app 0x0000000108cb4360 Task4DProc(V4DTaskConcrete*) + 910 18 4d.com.Map Server.app 0x0000000108cfb6c8 V4DTaskManager::_Task4DProc(xbox::VTask*) + 160 19 com.4d.kernel 0x000000010b0b02ee xbox::VTask::_Run() + 78 20 com.4d.kernel 0x000000010b0b54d6 xbox::XMacTask_fiber::_ThreadProc(void*) + 70 21 com.4d.kernel 0x000000010b0ef27f xbox::VMacFiber_thread::_ThreadProc(void*) + 31 22 com.apple.CoreServices.CarbonCore 0x00007fff476e6072 CooperativeThread + 282 23 libsystem_pthread.dylib 0x00007fff6e6ba661 _pthread_body + 340 24 libsystem_pthread.dylib 0x00007fff6e6ba50d _pthread_start + 377 25 libsystem_pthread.dylib 0x00007fff6e6b9bf9 thread_start + 13 > On Aug 6, 2018, at 9:26 AM, Randy Jaynes via 4D_Tech <[email protected]> > wrote: > > Ok. So moving our STARTUP method into a stored procedure using > $procID:=New Process(“STARTUP”;512000;”On Server Startup) > > takes care of BOTH problems. > > So it looks like the Application Server process on 4D Server v16R6 and higher > is more sensitive to interface related commands like > OPEN WINDOW > SET MENU BAR > DISPLAY RECORD > > For the record, this startup method was fine up through 4D v15.4 HF3. ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
