[haiku-gsoc] [HCD]: Bfs bug #1
- From: "Salvatore Benedetto" <emitrax@xxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Wed, 18 Jun 2008 08:04:28 +0000
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
Other related posts:
