[haiku-gsoc] Re: [HCD]: Bfs bug #1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Wed, 18 Jun 2008 11:31:11 +0200 CEST
"Salvatore Benedetto" <emitrax@xxxxxxxxx> wrote:
> 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.
Good luck! :-)
[...]
> 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.
It's allocated on the stack - the constructor cannot fail.
> 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);
While Get() is called in this case, the destructor would only work
correctly in case get_vnode() succeeded. Looks like I managed to put a
bug in that mini class Vnode...
If you want to fix that, please do, otherwise I can fix it on Monday.
The more interesting question would be why get_vnode() failed in the
first place, though.
> 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
I don't get that. What is where, and what comment describes it?
> 2. How is it atomic? I don't see where the interrupts are disabled.
At least you're not afraid to ask stupid questions ;-)) (sorry,
couldn't resist :-))
But seriously, if you're interested, have a look at the "Intel IA-32
Software Developer's Manual".
In short, the "lock" instruction takes care of making this atomic; it's
the sole purpose of it.
Bye,
Axel.
Other related posts:
