(Illustration by Gaich Muramatsu)
Hi, gurus, We have getten it fixed. The problem existed from that we didn't tell the node type during _readdir( ) Thanks for your notice/glance :) /yftty yf-263 wrote: > Hi, Quinn, > > Following is output of all bt: > > (gdb) thread apply all bt > > Thread 2 (process 1137 thread 0x5b33): > #0 0x90293508 in getdirentries_exhaustive(int, unsigned long*) () > #1 0x9028a6d8 in DCBlock_BuildContents(int, DCBlock*) () > #2 0x9029aa60 in DCBlock_Create(VolumeInfo const*, unsigned long, > DCBlock**) () > #3 0x90290550 in GetIndexedDirectoryItem(VolumeInfo*, unsigned long, > unsigned long, unsigned long, char*, unsigned char*) () > #4 0x9028c3cc in POSIXMount::getattrsbulk(void*, unsigned long, > unsigned long*, unsigned long, unsigned long, FSAttributeInfo*, > unsigned char*) () > #5 0x9028d310 in PBGetCatalogInfoBulkSync () > #6 0x902a2104 in FSGetCatalogInfoBulk () > #7 0x9091d494 in THFSPlusIterator::Next(THFSPlusRef&) () > #8 0x9092b6dc in THFSPlusIterator::First(THFSPlusRef&) () > #9 0x9091d40c in THFSPlusIterator::Next(THFSPlusRef&) () > #10 0x9091c4d0 in THFSPlusSynchronizer::Next(THFSPlusStore&) () > #11 0x9091f724 in THFSPlusStore::CreateChildren(TChildrenList&, > TNodeTask*) () > #12 0x9092b610 in TNode::CreateChildren(TNode::StInitialCreate const&, > TNodeTask*) () > #13 0x90923964 in TNodeOpenSyncTask::OpenSyncTaskProc(void*) () > #14 0x902c6da8 in PrivateMPEntryPoint () > #15 0x900246e8 in _pthread_body () > > Thread 1 (process 1137 thread 0x40b): > #0 0x90014528 in semaphore_wait_trap () > #1 0x900021f0 in pthread_mutex_lock () > #2 0x90281798 in TSLockMutex () > #3 0x90284584 in IsForkedDirectoryItem(VolumeInfo*, unsigned long, > char const*, unsigned char*) () > #4 0x90288efc in POSIXMount::getattrscore(bool, char const*, char > const*, POSIXNode*, unsigned long, FSAttributeInfo*, unsigned long, > unsigned char*) () > #5 0x90298584 in POSIXMount::_getattrs(unsigned long, char const*, > unsigned long, unsigned long, FSAttributeInfo*, unsigned long, > unsigned char*) () > #6 0x902888c8 in FSMount::getattrs(unsigned long, char const*, > unsigned long, unsigned long, FSAttributeInfo*, unsigned long, > unsigned char*) () > #7 0x9028ba90 in GetFSRefAttributes(FSMount*, FSRefPrivate const*, > unsigned long, FSAttributeInfo*, unsigned long, char*) () > #8 0x9028bb3c in PBGetCatalogInfoSync () > #9 0x902955d8 in FSGetCatalogInfo () > #10 0x902a62e0 in AL_fillInternalAliasRecord () > #11 0x902a7e88 in AL_fillAlias () > #12 0x902c0c90 in AL_newAliasCommon () > #13 0x902cf45c in FSNewAlias () > #14 0x0005200c in ?? () > #15 0x00051dd0 in ?? () > #16 0x000251b4 in ?? () > #17 0x0002a898 in ?? () > #18 0x0003f100 in ?? () > #19 0x0003eae8 in ?? () > #20 0x0003e92c in ?? () > #21 0x0002c36c in ?? () > #22 0x000439d0 in ?? () > #23 0x00073dc8 in ?? () > #24 0x0005c71c in ?? () > #25 0x0002734c in ?? () > #26 0x0009da18 in ?? () > #27 0x0005c128 in ?? () > #28 0x0002fe3c in ?? () > #29 0x0005ba60 in ?? () > #30 0x0005b8b4 in ?? () > #31 0x0005b874 in ?? () > #32 0x0005b75c in ?? () > #33 0x0005b100 in ?? () > #34 0x0000f954 in ?? () > #35 0x00021990 in ?? () > #36 0x0000a078 in ?? () > #37 0x0000ca54 in ?? () > #38 0x927d2330 in DispatchEventToHandlers () > #39 0x927d25a4 in SendEventToEventTargetInternal () > #40 0x927e4a34 in SendEventToEventTarget () > #41 0x927f31b4 in HandleMouseEventForWindow(OpaqueWindowPtr*, > OpaqueEventRef*, unsigned short) () > #42 0x927e8ad0 in HandleMouseEvent(OpaqueEventRef*) () > #43 0x927e2fd4 in > ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, > OpaqueEventRef*, void*) () > #44 0x927d23ec in DispatchEventToHandlers () > #45 0x927d25a4 in SendEventToEventTargetInternal () > #46 0x927e4a34 in SendEventToEventTarget () > #47 0x927e892c in ToolboxEventDispatcher () > #48 0x92805c5c in HLTBEventDispatcher () > #49 0x927fbaf8 in RunApplicationEventLoop () > #50 0x00035798 in ?? () > #51 0x00034090 in ?? () > #52 0x0003313c in ?? () > #53 0x00032fb0 in ?? () > (gdb) > > > > Quinn wrote: > >> At 11:37 +0800 22/10/04, yf-263 wrote: >> >>> Recently we ported a Linux FS to Darwin, and it can works in CLE. >>> But on >>> openning with Finder, it always hangs with following info: >>> >>> Can anyone give us some hints about it here ? >> >> >> >> This backtrace isn't very useful because it only shows one thread, >> and that thread is blocked waiting for a mutex that arbitrates access >> to Core Services File Manager's AppleDouble code. Can you post the >> results of: >> >> (gdb) thread apply all bt >> >> S+E > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel_at_lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/yfyoufeng%40263.net > > This email sent to yfyoufeng_at_263.net > > _______________________________________________ Darwincoda mailing list Darwincoda_at_opendarwin.org http://www.opendarwin.org/mailman/listinfo/DarwinCodaReceived on 2004-11-03 00:37:06