I had a very stable 16 user database with 4D 15 32-bit Mac. After upgrading to 4D 16 64-bit Mac (on 16.3HF4), 4D server has been crashing about twice a month. There is no consistency on the process or records involved in the crash. The only consistency is the backtrace of the internal 4D routines involved. Here are some samples.
Thread 93 Crashed:: Import (id = 133091) 0 libsystem_kernel.dylib 0x00007fff7f337b6e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff7f502080 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff7f2931ae abort + 127 3 libsystem_malloc.dylib 0x00007fff7f39cad4 szone_error + 596 4 libsystem_malloc.dylib 0x00007fff7f39e0eb small_free_list_remove_ptr_no_clear + 790 5 libsystem_malloc.dylib 0x00007fff7f392061 small_malloc_from_free_list + 171 6 libsystem_malloc.dylib 0x00007fff7f390859 szone_malloc_should_clear + 1600 7 libsystem_malloc.dylib 0x00007fff7f3901bd malloc_zone_malloc + 103 8 libsystem_malloc.dylib 0x00007fff7f38f4c7 malloc + 24 9 com.4d.component.db4d 0x000000010f052e19 VDBCacheMgr::NewPtr(unsigned long, unsigned char, int, int) + 25 10 com.4d.component.db4d 0x000000010f399c00 TreeMem::PutInto(int, int, void*, OccupableStack*) + 256 11 com.4d.component.db4d 0x000000010f39e26c TreeMemHeader::PutIntoTreeMem(int, int, void*, OccupableStack*) + 428 12 com.4d.component.db4d 0x000000010f125e2d DataTableRegular::LoadRecord(int, unsigned long long&, DB4D_Way_of_Locking, BaseTaskInfo*, unsigned char, unsigned char, ReadAheadBuffer*, unsigned char*) + 1053 Thread 77 Crashed:: CWR Export (id = 170783) 0 com.4d.component.db4d 0x000000010f95ea6b TreeMem::RetainFrom(int, int, OccupableStack*) + 139 1 com.4d.component.db4d 0x000000010f95ea9e TreeMem::RetainFrom(int, int, OccupableStack*) + 190 2 com.4d.component.db4d 0x000000010f9636eb TreeMemHeader::RetainFromTreeMem(int, OccupableStack*) + 75 3 com.4d.component.db4d 0x000000010f6eb7f7 DataTableRegular::LoadNotFullRecord(int, unsigned long long&, DB4D_Way_of_Locking, BaseTaskInfo*, unsigned char, ReadAheadBuffer*, unsigned char*, unsigned char*) + 583 4 com.4d.component.db4d 0x000000010f6df737 DataTable::Search(unsigned long long&, RechNode*, Bittab*, xbox::VProgressIndicator*, BaseTaskInfo*, DB4D_Way_of_Locking, Bittab*, int, Bittab&, LocalEntityModel*) + 3239 5 com.4d.component.db4d 0x000000010f8389d3 RechNode::Perform(OptimizedQuery*, Bittab**, Bittab*, xbox::VProgressIndicator*, xbox::VValueBag*, BaseTaskInfo*, DB4D_Way_of_Locking, Bittab*, int, Bittab&, RechNode*&) + 163 6 com.4d.component.db4d 0x000000010f8469ca RechNodeMultiOperator::Perform(OptimizedQuery*, Bittab**, Bittab*, xbox::VProgressIndicator*, xbox::VValueBag*, BaseTaskInfo*, DB4D_Way_of_Locking, Bittab*, int, Bittab&, RechNode*&) + 2058 7 com.4d.component.db4d 0x000000010f84da5f OptimizedQuery::Perform(Bittab*, xbox::VProgressIndicator*, BaseTaskInfo*, unsigned long long&, DB4D_Way_of_Locking, int, Bittab*) + 1903 8 com.4d.component.db4d 0x000000010f6e0f12 DataTable::ExecuteQuery(SearchTab*, QueryOptions*, QueryResult&, BaseTaskInfo*, xbox::VProgressIndicator*) + 322 9 com.4d.component.db4d 0x000000010f690933 VDBMgr::ExecExecuteQuery(IRequestReply*, CDB4DBaseContext*) + 259 10 com.4d.component.db4d 0x000000010f688253 VDBMgr::ExecuteRequest(short, IRequestReply*, CDB4DBaseContext*) + 1475 11 com.4d.component.db4d 0x000000010f697697 VDBMgr::ExecuteRequest(short, xbox::IStreamRequestReply*, CDB4DContext*) + 311 12 com.4d.component.db4d 0x000000010f9a4a64 DB4DConnectionHandler::Handle(unsigned long long&) + 2036 So it appears that 4D is crashing shortly after loading a record (DataTableRegular::LoadRecord, DataTableRegular::LoadNotFullRecord). The database is validated every night and reports no errors. Manual check in MSC reports no errors. With no other solution in sight, it is time to compact the database (70+ GB) and see if it makes a difference. Here is what happens. 1. Open MSC, click on Compact, click on Advanced. Check "Force updating of the records" and "Compact address table". Click the compact button. The first bit of confusion is the path under "Original files backup folder" is *not* a backup of the original database. It is the new compacted database. 2. Wait for hours and the progress bar finally reaches the last table and is pixels away from the end. Wait for many more hours, nothing seems to be happening even though 4D is using 100% CPU. Finally discover that 4D is indexing the database, but the indexing progress window is hidden behind the MSC window. 3. Wait many more hours, progress bar for creation of a single index on a table with 40 million records has barely moved. Cache used in creation of the index shows 0%. The database memory setting is 4GB. Activity Monitor shows 4D is using 300MB. I suspect when 4D restarts to open the database for compacting that it ignores the database memory settings. Indexing will never complete under these conditions. 4. Force 4D to quit. Trash the index file. Remove the "_" prefix from the database in "Original files backup folder", then open the database. It re-indexes normally with plenty of cache available. My experience with compacting was the same using 4D 16.3HF4 and 17.0. Anyone have a better experience with this on a large data file? John DeSoi, Ph.D. ********************************************************************** 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] **********************************************************************
