Hi there, it looks like I hit my first bug (#2400) while unpacking a tarball containing the whole haiku tree (about 480MB compressed) from a usbstick while running in vmware. Last night, I followed the stack trace to figure out the crash. The destructor of VNode is called I guess, because the constructor for some reason fails to create the object due to memory problem as the constructor seems pretty straightforward to me. Vnode(Volume *volume, ino_t id) : fVolume(volume), fID(id) { } Here is a summary: Index::SetTo() is called, it tries to create a Vnode object Vnode vnode(fVolume, id); thus with this signature Vnode(Volume *volume, ino_t id), but then the destructor gets called. Actually, now that I look at it, it might fail because the Volume constructor fails first. I'm not C++ guru, but I thought that if one of the initialization would fail, the object wouldn't be created without any needs to call the destructor. Anyhow, the ~Vnode gets called, that in turn calls Put() void Put() { if (fVolume) put_vnode(fVolume->FSVolume(), fID); fVolume = NULL; } ... dec_vnode_ref_count(vnode, false); ... int32 oldRefCount = atomic_add(&vnode->ref_count, -1); ASSERT( oldRefCount > 0) ... KDL. By the way, two things about atomic_add: 1. As already stated in the comment above the function, it is in a unusual place src/add-ons/kernel/partitioning_systems/intel/intel.cpp 2. How is it atomic? I don't see where the interrupts are disabled. Any comments? Regards, -- Salvatore Benedetto (a.k.a. emitrax) Student of Computer Engineer University of Pisa www.haiku-os.it