You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Ernst Albrecht Köstlin (JIRA)" <ji...@apache.org> on 2010/06/03 12:35:00 UTC
[jira] Created: (HARMONY-6542) java.io.RandomAccessFile.seek
troughs exception on calls with "pos" set to values larger then 0x7FFFFFFF
java.io.RandomAccessFile.seek troughs exception on calls with "pos" set to values larger then 0x7FFFFFFF
--------------------------------------------------------------------------------------------------------
Key: HARMONY-6542
URL: https://issues.apache.org/jira/browse/HARMONY-6542
Project: Harmony
Issue Type: Bug
Components: Classlib
Environment: Linux (Debian Lenny)
Reporter: Ernst Albrecht Köstlin
Dear Community
.
Calling to java.io.RandomAccessFile.seek (long pos) through an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
Change this casting does it for windows.
To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
Thanks and happy hacking...
Kind regards
/a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Ernst Albrecht Köstlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877524#action_12877524 ]
Ernst Albrecht Köstlin commented on HARMONY-6542:
-------------------------------------------------
Hi Mark
Thanks for applying the patch...! :-)
And yes: Things looks good.
regards
/a
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-6542) java.io.RandomAccessFile.seek (long
pos) throughs exception on calls with "pos" set to values larger then
0x7FFFFFFF
Posted by "Ernst Albrecht Köstlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ernst Albrecht Köstlin updated HARMONY-6542:
--------------------------------------------
Summary: java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values larger then 0x7FFFFFFF (was: java.io.RandomAccessFile.seek troughs exception on calls with "pos" set to values larger then 0x7FFFFFFF)
Environment: 32bit Linux/windows (was: Linux (Debian Lenny))
Priority: Minor (was: Major)
Description:
Dear Community
.
Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
Change this casting does it for windows.
To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
Thanks and happy hacking...
Kind regards
/a
was:
Dear Community
.
Calling to java.io.RandomAccessFile.seek (long pos) through an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
Change this casting does it for windows.
To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
Thanks and happy hacking...
Kind regards
/a
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values larger then 0x7FFFFFFF
> --------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Priority: Minor
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-6542) java.io.RandomAccessFile.seek (long
pos) throughs exception on calls with "pos" set to values greater then
0x7FFFFFFF
Posted by "Ernst Albrecht Köstlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ernst Albrecht Köstlin updated HARMONY-6542:
--------------------------------------------
Summary: java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF (was: java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values larger then 0x7FFFFFFF)
Priority: Major (was: Minor)
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Ernst Albrecht Köstlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877517#action_12877517 ]
Ernst Albrecht Köstlin commented on HARMONY-6542:
-------------------------------------------------
I had someone integrate this patch into a Hy5 build for windows and was
told files up to 8GB could have been read.
Regards
/a
--
Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata.
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881622#action_12881622 ]
Hudson commented on HARMONY-6542:
---------------------------------
Integrated in Harmony-select-1.5-head-linux-x86_64 #38 (See [http://hudson.zones.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/38/])
Add regression test for "[#HARMONY-6542] java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with 'pos' set to values
greater then 0x7FFFFFFF". Only works for unix platforms but that's better
than not having one.
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-6542) java.io.RandomAccessFile.seek (long
pos) throughs exception on calls with "pos" set to values greater then
0x7FFFFFFF
Posted by "Mark Hindess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Hindess reassigned HARMONY-6542:
-------------------------------------
Assignee: Mark Hindess
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Ernst Albrecht Köstlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877521#action_12877521 ]
Ernst Albrecht Köstlin commented on HARMONY-6542:
-------------------------------------------------
And actually seek arounded in.... |-}
/a
--
Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata.
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-6542) java.io.RandomAccessFile.seek (long
pos) throughs exception on calls with "pos" set to values larger then
0x7FFFFFFF
Posted by "Ernst Albrecht Köstlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ernst Albrecht Köstlin updated HARMONY-6542:
--------------------------------------------
Attachment: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
Patch to allow calls to RandomAccessFile.seek (long pos) for Hy5M1 (32bit) work for pos >0x7FFFFFFF
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values larger then 0x7FFFFFFF
> --------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Priority: Minor
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Ernst Albrecht Köstlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877522#action_12877522 ]
Ernst Albrecht Köstlin commented on HARMONY-6542:
-------------------------------------------------
should read: "... seeked around ... " sry
--
Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata.
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-6542) java.io.RandomAccessFile.seek (long
pos) throughs exception on calls with "pos" set to values greater then
0x7FFFFFFF
Posted by "Ernst Albrecht Köstlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ernst Albrecht Köstlin updated HARMONY-6542:
--------------------------------------------
Affects Version/s: 5.0M13
6.0M1
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Mark Hindess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877252#action_12877252 ]
Mark Hindess commented on HARMONY-6542:
---------------------------------------
I've applied your patch at r953177. Please confirm that it has been applied as expected and that the issue is resolved.
Normally I ask for confirmation by simply closing this JIRA but I'd like to come up with a regression test first. However, I tried using the following (in the context of the existing test):
// Regression test for HARMONY-6542
public void testRandomAccessFile_seekMoreThan2gb() throws IOException {
RandomAccessFile raf = new RandomAccessFile(f, "rw");
// write a few bytes so we get more helpful error messages
// if we land in the wrong places
raf.write(1);
raf.write(2);
raf.seek(2147483647);
raf.write(3);
raf.write(4);
raf.write(5);
raf.write(6);
raf.seek(0);
assertEquals("seek 0", 1, raf.read());
raf.seek(2147483649L);
assertEquals("seek >2gb", 5, raf.read());
raf.seek(0);
assertEquals("seek back to 0", 1, raf.read());
raf.close();
}
and this fails without your fix and passes with it as expected. Any (by virtue of the use of sparse files) passes even if less than 2GB of free disk space are available. However, this test fails on windows for me even with the fix (though I assume this is because I have less than 2GB of space available). Does anyone know how to write a regression test that uses sparse files on windows?
Or should the above use sparse files and it just doesn't work because the fix is incomplete?
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881628#action_12881628 ]
Hudson commented on HARMONY-6542:
---------------------------------
Integrated in Harmony-1.5-head-linux-x86_64 #859 (See [http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/859/])
Add regression test for "[#HARMONY-6542] java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with 'pos' set to values
greater then 0x7FFFFFFF". Only works for unix platforms but that's better
than not having one.
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-6542) java.io.RandomAccessFile.seek (long
pos) throughs exception on calls with "pos" set to values greater then
0x7FFFFFFF
Posted by "Mark Hindess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Hindess resolved HARMONY-6542.
-----------------------------------
Resolution: Fixed
I've added a regression test (for unix only since windows would always need 2GB free disk space to pass) at r957142. I've asked around and no one seems to have a good solution for windows so I am going to close this issue.
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877265#action_12877265 ]
Hudson commented on HARMONY-6542:
---------------------------------
Integrated in Harmony-1.5-head-linux-x86_64 #837 (See [http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/837/])
Applying patch from "[#HARMONY-6542] java.io.RandomAccessFile.seek(long pos)
throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF".
I'd still like to write a regression test but need help to find one that works
on windows.
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Mark Hindess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875523#action_12875523 ]
Mark Hindess commented on HARMONY-6542:
---------------------------------------
Thanks for this contribution. Could you please complete ICLAs and ACQs as mentioned at:
http://harmony.apache.org/contribution_policy.html
Sign them, scan them and email them to private@harmony.apache.org.
Thanks,
Mark.
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-6542) java.io.RandomAccessFile.seek (long
pos) throughs exception on calls with "pos" set to values greater then
0x7FFFFFFF
Posted by "Mark Hindess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Hindess closed HARMONY-6542.
---------------------------------
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with "pos" set to values greater
then 0x7FFFFFFF
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877309#action_12877309 ]
Hudson commented on HARMONY-6542:
---------------------------------
Integrated in Harmony-select-1.5-head-linux-x86_64 #25 (See [http://hudson.zones.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/25/])
Applying patch from "[#HARMONY-6542] java.io.RandomAccessFile.seek(long pos)
throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF".
I'd still like to write a regression test but need help to find one that works
on windows.
> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-6542
> URL: https://issues.apache.org/jira/browse/HARMONY-6542
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1, 5.0M13
> Environment: 32bit Linux/windows
> Reporter: Ernst Albrecht Köstlin
> Assignee: Mark Hindess
> Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
> The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.