Skip Menu | Logged in as guest | Logout
 
The Basics
Id: 3864
Status: open
Priority: 3/
Queue: vdt-support
Fixed in: (no value)
Fix scheduled: OLD
Request Type: 51375

Dates
Created: Thu Aug 28 17:12:44 2008
Starts: Not set
Started: Not set
Last Contact: Tue May 10 02:20:49 2011
Due: Not set
Closed: Mon Nov 03 15:31:02 2008
Updated: Tue May 10 02:20:49 2011 by guest

History Brief headersFull headers
CC: Maarten LITMAATH <Maarten.Litmaath@cern.ch>, Andreas Unterkircher <andreas.unterkircher@cern.ch>
Subject: vdt/globus build issue on 64bit
Date: Thu, 28 Aug 2008 18:23:38 +0200
To: Alain Roy <roy@cs.wisc.edu>
From: Oliver Keeble <oliver.keeble@cern.ch>
Download (untitled)
text/plain 559b
Hi Alain,

We've uncovered an issue with the 32bit support in the 64bit
vdt_globus_essentials. Please see comment #6 here;

https://savannah.cern.ch/bugs/index.php?40734

We're now pushing our 64bit WN so this could be uncomfortable for us,
but I think the fix is easy. Could you give us a timescale for updated
rpms? Thanks a lot,

Oliver.

--
Oliver Keeble Information Technology Department
oliver.keeble@cern.ch CERN
+41 22 76 72360 CH-1211 Geneva 23
Download (untitled)
text/plain 1k
On Thu Aug 28 17:12:44 2008, oliver.keeble@cern.ch wrote:
> Hi Alain,
>
> We've uncovered an issue with the 32bit support in the 64bit
> vdt_globus_essentials. Please see comment #6 here;
>
> https://savannah.cern.ch/bugs/index.php?40734

I'm not sure I fully understand. I see David's message:

>vdt_globus_essentials (VDT1.6.0x86_64_rhas_4-1,
>VDT1.6.1x86_64_rhas_4-6, VDT1.6.1x86_rhas_4-7)
>
>the 32bit version of the builds incorrecty defines
>
>GLOBUS_OFF_T_FORMAT

>as 'd' rather than 'qd' (as it is defined in the 32bit RPMs).

I think that GLOBUS_OFF_T_FORMAT actually comes from vdt_compile_globus,
which is why I'm double-checking here.

It sounds like this should be a simple rebuild, but globus_config is
generated, not just checked into the source code. So it will take a
little bit of work to investigate what is going on. I'll take this as a
high priority task for you.

Question: Do you know exactly what GLOBUS_OFF_T_FORMAT is for?

Thanks, I'll investigate right away and keep you up to date.

-alain
CC: oliver.keeble@cern.ch, Andreas.Unterkircher@cern.ch
Subject: Re: [vdt-support #3864] vdt/globus build issue on 64bit
Date: Fri, 29 Aug 2008 00:31:13 +0200
To: Alain Roy via RT <vdt-support@OPENSCIENCEGRID.ORG>, David.Smith@cern.ch
From: Maarten.Litmaath@cern.ch
Download (untitled)
text/plain 1.1k
Hi Alain,
CC'ing David for advice.
Thanks,
Maarten

> On Thu Aug 28 17:12:44 2008, oliver.keeble@cern.ch wrote:
> > Hi Alain,
> >
> > We've uncovered an issue with the 32bit support in the 64bit
> > vdt_globus_essentials. Please see comment #6 here;
> >
> > https://savannah.cern.ch/bugs/index.php?40734
>
> I'm not sure I fully understand. I see David's message:
>
> >vdt_globus_essentials (VDT1.6.0x86_64_rhas_4-1,
> >VDT1.6.1x86_64_rhas_4-6, VDT1.6.1x86_rhas_4-7)
> >
> >the 32bit version of the builds incorrecty defines
> >
> >GLOBUS_OFF_T_FORMAT
>
> >as 'd' rather than 'qd' (as it is defined in the 32bit RPMs).
>
> I think that GLOBUS_OFF_T_FORMAT actually comes from vdt_compile_globus,
> which is why I'm double-checking here.
>
> It sounds like this should be a simple rebuild, but globus_config is
> generated, not just checked into the source code. So it will take a
> little bit of work to investigate what is going on. I'll take this as a
> high priority task for you.
>
> Question: Do you know exactly what GLOBUS_OFF_T_FORMAT is for?
>
> Thanks, I'll investigate right away and keep you up to date.
>
> -alain
>
>
>
CC: Oliver Keeble <oliver.keeble@cern.ch>, Andreas Unterkircher <Andreas.Unterkircher@cern.ch>
Subject: Re: [vdt-support #3864] vdt/globus build issue on 64bit
Date: Fri, 29 Aug 2008 10:49:28 +0200
To: "maarten.litmaath@cern.ch> Litmaath" <Maarten.Litmaath@cern.ch>, Alain Roy via RT <vdt-support@OPENSCIENCEGRID.ORG>
From: David Smith <David.Smith@cern.ch>
Download (untitled)
text/plain 1.3k

On Aug 29, 2008, at 12:31 AM, <Maarten.Litmaath@cern.ch> wrote:

> Hi Alain,
> CC'ing David for advice.

Hi,

In the ticket I was only describing the immediate cause of the problem
in the library where it was hitting us for that specific problem - I
did not see exactly where it needs to be fixed.

Most likely the preprocessor macro is value is determined as part of
the build preparation. As well as GLOBUS_OFF_T_FORMAT there are likely
to be other, linked macros, such as GLOBUS_OFF_T. These are defining
the printf/scanf format specifiers and storage type for the type that
globus uses to represent offsets. (including lengths). The 32bit RPM
build has this defined such that 64 bit offsets can be represented and
stored, while the 32bit libraries in the 64bit RPM seem to have it
setup to only be able to represent 32 bit offsets. In itself that
would limit file lengths to 4GB (or possibly 2GB) - or if an
application is build with one version and run against the other it
gives corruption or incorrect lengths.

Yours,
David

--
-------------------------------------------------------------------------
David Smith e-mail: David.Smith@cern.ch tel: +41 22 76
70677
Address: D. Smith, CERN G20800, Bat 31 2-003, 1211 Geneva 23,
Switzerland
-------------------------------------------------------------------------
Download smime.p7s
application/pkcs7-signature 4.2k

Message body not shown because it is not plain text.

Subject: Re: [vdt-support #3864] vdt/globus build issue on 64bit
Date: Fri, 29 Aug 2008 09:47:20 -0700
To: vdt-support@OPENSCIENCEGRID.ORG
From: Alain Roy <roy@cs.wisc.edu>
Download (untitled)
text/plain 1.4k
On Aug 29, 2008, at 1:57 AM, David.Smith@cern.ch via RT wrote:

> http://crt.cs.wisc.edu/Ticket/Display.html?id=3864
>
>
> On Aug 29, 2008, at 12:31 AM, <Maarten.Litmaath@cern.ch> wrote:
>
>> Hi Alain,
>> CC'ing David for advice.
>
> Hi,
>
> In the ticket I was only describing the immediate cause of the problem
> in the library where it was hitting us for that specific problem - I
> did not see exactly where it needs to be fixed.

Right, good. I have a suspicion of what chunk of code needs to be
fixed (globus_core), but not the details.

> Most likely the preprocessor macro is value is determined as part of
> the build preparation. As well as GLOBUS_OFF_T_FORMAT there are likely
> to be other, linked macros, such as GLOBUS_OFF_T. These are defining
> the printf/scanf format specifiers and storage type for the type that
> globus uses to represent offsets. (including lengths). The 32bit RPM
> build has this defined such that 64 bit offsets can be represented and
> stored, while the 32bit libraries in the 64bit RPM seem to have it
> setup to only be able to represent 32 bit offsets. In itself that
> would limit file lengths to 4GB (or possibly 2GB) - or if an
> application is build with one version and run against the other it
> gives corruption or incorrect lengths.

thanks, I'll look into it and get back to you.

Monday is a US holiday. While I will be at work on Tuesday, I'l be off
the rest of the week. Tim Cartwright may help out with this ticket in
my absence.

-alain
Download (untitled)
text/plain 857b
I've looked into this a bit. It is also a problem with the newer VDT
1.10.1. I don't understand the source of the problem at all, so I've
reported it as a Globus bug. You can see the bug here:

http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6348

I'm going to be gone the rest of this week, so Tim will follow the state
of the bug. Assuming we find a resolution, Tim will start a new build
with a patch this week, or I'll do it next week.

Tim--one possibility to investigate: We might be shipping an older
version of GPT, and GPT includes globus_core. If there is a newer
version of globus_core and/or GPT, it might fix this problem.

Thanks,
-alain

-----------------------------------------------------------------
Alain Roy vdt-support@opensciencegrid.org
VDT Support http://vdt.cs.wisc.edu/support.html
CC: oliver.keeble@cern.ch, Andreas.Unterkircher@cern.ch, David.Smith@cern.ch
Subject: Re: [vdt-support #3864] vdt/globus build issue on 64bit
Date: Mon, 20 Oct 2008 19:27:21 +0200
To: vdt-support@OPENSCIENCEGRID.ORG
From: Maarten Litmaath <Maarten.Litmaath@cern.ch>
Download (untitled)
text/plain 836b
Hi Alain,

> I've looked into this a bit. It is also a problem with the newer VDT
> 1.10.1. I don't understand the source of the problem at all, so I've
> reported it as a Globus bug. You can see the bug here:
>
> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6348
>
> I'm going to be gone the rest of this week, so Tim will follow the state
> of the bug. Assuming we find a resolution, Tim will start a new build
> with a patch this week, or I'll do it next week.
>
> Tim--one possibility to investigate: We might be shipping an older
> version of GPT, and GPT includes globus_core. If there is a newer
> version of globus_core and/or GPT, it might fix this problem.

Globus have marked the bug as RESOLVED FIXED: when might we see new rpms?
Sites with 64-bit worker nodes need to do awkward workarounds...
Thanks,
Maarten
Subject: Re: [vdt-support #3864] vdt/globus build issue on 64bit
Date: Mon, 20 Oct 2008 16:41:20 -0500
To: vdt-support@OPENSCIENCEGRID.ORG
From: Alain Roy <roy@cs.wisc.edu>
Download (untitled)
text/plain 1.2k
On Oct 20, 2008, at 3:31 PM, Maarten.Litmaath@cern.ch via RT wrote:
>> I've looked into this a bit. It is also a problem with the newer VDT
>> 1.10.1. I don't understand the source of the problem at all, so I've
>> reported it as a Globus bug. You can see the bug here:
>>
>> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6348
>>
>> I'm going to be gone the rest of this week, so Tim will follow the
>> state
>> of the bug. Assuming we find a resolution, Tim will start a new build
>> with a patch this week, or I'll do it next week.
>>
>> Tim--one possibility to investigate: We might be shipping an older
>> version of GPT, and GPT includes globus_core. If there is a newer
>> version of globus_core and/or GPT, it might fix this problem.
>
> Globus have marked the bug as RESOLVED FIXED: when might we see new
> rpms?
> Sites with 64-bit worker nodes need to do awkward workarounds...

Right, I just saw that today.

At this point, I'm confused as to which version of the VDT's Globus
EGEE/LCG wants. I've been updating 1.6.1, 1.8.1, and 1.10.1 in
response to various requests. What would you like?

Thanks,
-alain

-----------------------------------------------------------------
Alain Roy vdt-support@opensciencegrid.org
VDT Support http://vdt.cs.wisc.edu/support.html
CC: oliver.keeble@cern.ch, Andreas.Unterkircher@cern.ch, David.Smith@cern.ch
Subject: Re: [vdt-support #3864] vdt/globus build issue on 64bit
Date: Tue, 21 Oct 2008 00:02:55 +0200
To: Alain Roy via RT <vdt-support@OPENSCIENCEGRID.ORG>
From: Maarten.Litmaath@cern.ch
Download (untitled)
text/plain 352b
Hi Alain,

> At this point, I'm confused as to which version of the VDT's Globus
> EGEE/LCG wants. I've been updating 1.6.1, 1.8.1, and 1.10.1 in
> response to various requests. What would you like?

For now 1.6.1 would be best. AFAIK we will move to 1.10.x next,
but that will be a big change requiring a lot more certification.
Thanks,
Maarten
Subject: Re: [vdt-support #3864] vdt/globus build issue on 64bit
Date: Tue, 21 Oct 2008 14:54:39 -0500
To: vdt-support@OPENSCIENCEGRID.ORG
From: Alain Roy <roy@cs.wisc.edu>
Download (untitled)
text/plain 562b
On Oct 20, 2008, at 5:05 PM, Maarten.Litmaath@cern.ch via RT wrote:
> http://crt.cs.wisc.edu/Ticket/Display.html?id=3864
>
> Hi Alain,
>
>> At this point, I'm confused as to which version of the VDT's Globus
>> EGEE/LCG wants. I've been updating 1.6.1, 1.8.1, and 1.10.1 in
>> response to various requests. What would you like?
>
> For now 1.6.1 would be best. AFAIK we will move to 1.10.x next,
> but that will be a big change requiring a lot more certification.

Yes, I also heard from Andreas. I'll work out an update. I'm looking
at it right now.

-alain
Download (untitled)
text/plain 46b
I gave this to EGEE on October 31st.

-alain
Subject: wLkSadTOUyVwdMvxGZ
Download (untitled)
text/plain 187b
Lh7daS <a href="http://xcwqpdfizwvk.com/">xcwqpdfizwvk</a>, [url=http://nnhescpxlvzu.com/]nnhescpxlvzu[/url], [link=http://pcczuwbcehrq.com/]pcczuwbcehrq[/link], http://wtssqapaeyej.com/