bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in GNU Parted


From: Andrew Clausen
Subject: Re: Bug in GNU Parted
Date: Mon, 14 May 2001 07:50:53 +1000

Wouter Coene wrote:
> > Exactly.  I want to find out why Parted "isn't programmed
> > according to the API".
> 
> Well, the code itself strikes me as rather odd, too. In version 1.4.9 (not
> the latest version, but I don't believe that part of the code has changed
> much lately, plus I don't have access to any newer versions right now),
> ped_device_close() (libparted/device.c:812) calls _do_refresh_close()
> (libparted/device.c:738) while decrementing dev->open_count. However, the
> contents of _do_refresh_close() is a mere:
> 
>         static int
>         _do_refresh_close (PedDevice* dev)
>         {
>                 return 1;
>         }

Well, there is nothing that needs to be done!  The idea is
to keep it abstract.

> I encountered this problem

Which problem?

> in a program I worked on some time ago too, but
> my patch (which is still in the version of parted I use to build said
> program) solved that nicely.
 
> I think it has something to do with dev->open_count being only incremented
> on the opening of the device by the disk layer, and that somehow right after
> the parted command-line editor is started, unlike the device layer, the disk
> layer remains uninitialized until a command is executed.

Right... ped_disk_open() only happens when you use a disk.
(Motivation: mklabel)

> This would also mean that, since ped_disk_close() closes the device (and
> thus decrements dev->open_count), there must be a small memory leak in the
> parted command line editor at program termination, caused by
> ped_disk_close() not being called for every opened disk "object", otherwise
> this problem would have been noticed earlier.

The bug Charles reported is the opposite... ped_device_close()
was being called too many times.

> ps: sorry about my previous post (which was rather rude I believe). I think
>     I'll blame the weather (hot and humid) for that one.

No problems ;-)  I do the same thing a bit, when I'm in a hurry :/

Andrew Clausen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]