osdir.com
mailing list archive

Subject: Re: Bug in mac_alloc - msg#00019

List: gnu.parted.bugs

Date: Prev Next Index Thread: Prev Next Index
On Tue, Jan 13, 2004 at 09:58:36AM +0000, Alex Kiernan wrote:
> --- parted-1.6.6.orig/libparted/disk_mac.c 2003-06-30 01:47:58.000000000
> +0100
> +++ parted-1.6.6/libparted/disk_mac.c 2004-01-04 03:11:40.000000000 +0000
> @@ -258,7 +258,7 @@
> goto error;
>
> mac_disk_data = (MacDiskData*) ped_malloc (sizeof (MacDiskData));
> - if (!disk->disk_specific)
> + if (!mac_disk_data)
> goto error_free_disk;
> disk->disk_specific = mac_disk_data;
> mac_disk_data->ghost_size = disk->dev->sector_size / 512;

You are correct.

Thanks!
Andrew


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: Problem building disk_sun.c

On Tue, Jan 13, 2004 at 10:08:49AM +0000, Alex Kiernan wrote: > On a big endian machine (PowerPC in my case), disk_sun.c fails to > build; I /think/ this is the right fix for the problem, but I can't > easily test it at the moment (it fixes the compile fwiw): > > --- parted-1.6.6.orig/libparted/disk_sun.c 2003-06-30 01:48:11.000000000 > +0100 > +++ parted-1.6.6/libparted/disk_sun.c 2004-01-04 09:34:36.000000000 +0000 > @@ -354,7 +354,7 @@ > if (!ped_device_read (disk->dev, &old_label, 0, 1)) > return; > if (old_label.info [0] > - && old_label.magic == PED_CPU_TO_LE32 (SUN_DISK_MAGIC)) > + && PED_BE16_TO_CPU(old_label.magic) == SUN_DISK_MAGIC) > memcpy (&sun_specific->raw_label, &old_label, 512); > } Yep, this one is already applied to the debian package, and i think i posted it here or something in july last year or something such. There are a couple of other stuff in the debian packages, nicely dpatchified by Peter, so it is easy to get the individual patches (look into the debian/patches directory, and you will find them). Friendly, Sven Luther

Next Message by Date: click to view message preview

STRICTLY COFIDENTIAL

FROM: THE DESK OF PRINCE TEODORO NGUEMA MBASOGO (JR TEL.:-0034-677256839. FAX 0034-635923852. E-MAIL:princeteo2004@xxxxxxxxxxxx I AM PRINCE TEODORO NGUEMA MBASOGO {JR}. THE SON OF PRESIDENT TEODORO OBIANG NGUEMA MBASOGO, THE PRESIDENT OF THE REPUBLIC OF EQUATORIAL GUINEA. AND I AM PRESENTLY LIVING IN {MADRID-SPAIN} EUROPE AND I SPEAK SPANISH VERY WELL AS IT IS OUR NATIVE LANGUAGE. MY FATHER HAS INSTRUCTED ME TO LOOK FOR A RELIABLE PARTNER WHO WILL TAKE CARE OF HIS FUND NOW DEPOSITED AT RIGGS BANK,DUPONT CIRCLE BRANCH,WASHINGTON USA. THE AMOUNT IN THE BANK IS THE SUM OF US$150 MILLION. THE JUST DEPARTMENT IS TRYING TO QUERRY WHY SUCH A HUGE AMOUNT OF MONEY IS IN MY FATHER'S ACCOUNT AND WE WANT TO MOVE THE MONEY OUT OF UNITED STATES OF AMERICA TO SPAIN WHERE WE KNOW BANKS THAT CAN KEEP THE MONEY WITHOUT RAISING EYE BROW. WHY WE NEED YOU IS THIS,WE NEED A TRUSTWORTHY SOMEBODY WHO WILL OPEN AN ACCOUNT IN SPAIN AND THE MONEY WILL BE MOVED FROM THE U.S.A ACCOUNT TO THE NEW ACCOUNT IN SPAIN. AFTER OPENING OF THE ACCOUNT WITH THE BANK IN SPAIN, WE SHALL GIVE YOU AN AUTHORIZATION TO RIGGS BANK TO TRANSFER THE MONEY BIT BY BIT INTO THE ACCOUNT YOU HAVE OPENED IN SPAIN. WE WANT SOMEBODY WHO HAS NO CONNECTION WITH US SO AS TO AVOID ANY LINK TO OUR FAMILY. THIS MONEY IS FREE FROM DRUG AND LAUNDERING AS WAS PAID INTO MY FATHER'S ACCOUNT BY EXXON MOBIL FOR CRUDE OIL LICENSE IN OUR COUNTRY. IF YOU ARE READY TO HELP,PLEASE REPLY IMMEDIATELY AND GIVE ME YOUR FULL CONTACT INFORMATIONS SUCH AS YOUR FULL NAME/ADDRESS, TEL/FAX NUMBERS. WE SHALL GIVE YOU 15% OF ANY AMOUNT TRANSFERED INTO THE NEW ACCOUNT AND YOU WILL HELP US IN INVESTING THE REST OF THE MONEY. THANK YOU. BEST REGARDS. TEODORO MBASOGO{JR}

Previous Message by Thread: click to view message preview

Bug in mac_alloc

The partition code in mac_alloc (in disk_mac.c) is broken over its usage of disk->disk_specific. If you trace back up the call chain, disk->disk_specific isn't initialised anywhere. If you're building DEBUG, ped_malloc happens to initialise it to -1 (assuming 0xffffffff == -1). In the RedHat RPM build there's a patch which causes it to be initialised to 0x00000000 (again if DEBUG, which the SPEC file will always generate), which causes that test to fail. The standard build "works" because disk->disk_specific will be non-NULL, but would SEGV if ped_malloc failed. The RedHat version fails on all mac partition tables because disk->disk_specific is always NULL. This patch fixes this: --- parted-1.6.6.orig/libparted/disk_mac.c 2003-06-30 01:47:58.000000000 +0100 +++ parted-1.6.6/libparted/disk_mac.c 2004-01-04 03:11:40.000000000 +0000 @@ -258,7 +258,7 @@ goto error; mac_disk_data = (MacDiskData*) ped_malloc (sizeof (MacDiskData)); - if (!disk->disk_specific) + if (!mac_disk_data) goto error_free_disk; disk->disk_specific = mac_disk_data; mac_disk_data->ghost_size = disk->dev->sector_size / 512; -- Alex Kiernan, Principal Engineer, Development, THUS plc

Next Message by Thread: click to view message preview

Problem building disk_sun.c

On a big endian machine (PowerPC in my case), disk_sun.c fails to build; I /think/ this is the right fix for the problem, but I can't easily test it at the moment (it fixes the compile fwiw): --- parted-1.6.6.orig/libparted/disk_sun.c 2003-06-30 01:48:11.000000000 +0100 +++ parted-1.6.6/libparted/disk_sun.c 2004-01-04 09:34:36.000000000 +0000 @@ -354,7 +354,7 @@ if (!ped_device_read (disk->dev, &old_label, 0, 1)) return; if (old_label.info [0] - && old_label.magic == PED_CPU_TO_LE32 (SUN_DISK_MAGIC)) + && PED_BE16_TO_CPU(old_label.magic) == SUN_DISK_MAGIC) memcpy (&sun_specific->raw_label, &old_label, 512); } -- Alex Kiernan, Principal Engineer, Development, THUS plc
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by