You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Daniel Gong <da...@gmail.com> on 2010/08/02 17:44:20 UTC
Problem met when building jdktools alone
Hi all,
As you know that I'm developing the jdb command line tool. I met a weird
problem when building jdktools alone.
Briefly, the problem is like this: after I build the jdktools module against
hdk, each jdk tool command line tool turns out to be segmentation fault when
running with a simple command such as "java", but succeeds when running with
a full path such as "$HDK/jdk/bin/java".
According to the component-wise instruction, I get the jdktools code and
common resources code from svn, the directory structure is like this:
myproject
|
|--------- jdktools
| |
| |---------- build.xml
| |
| |---------- LICENSE
| |
| |---------- make
| |
| |---------- modules
| |
| |---------- NOTICE
|
|--------- common resources
| |
| |---------- build.xml
| |
| |---------- depends
| |
| |---------- make
And hdk is in another directory. HDK is also the java runtime that ant use.
I have kept using the full path of jdk tool command to test whether my jdb
works and tried to find a solution but still do not have one...
Does any one know what happened? Thanks.
Best wishes
Daniel Gong
Re: Problem met when building jdktools alone
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4C...@gmail.com>, Regis writes:
>
> On 2010-08-02 23:44, Daniel Gong wrote:
> > Hi all,
> >
> > As you know that I'm developing the jdb command line tool. I met a weird
> > problem when building jdktools alone.
> >
> > Briefly, the problem is like this: after I build the jdktools module against
> > hdk, each jdk tool command line tool turns out to be segmentation fault when
> > running with a simple command such as "java", but succeeds when running with
> > a full path such as "$HDK/jdk/bin/java".
>
> [SNIP]
> getExeDir in samsa.c uses realpath to find executable file path, which can't
> handle case of executable file is in $PATH.
> Reading symbol link "/proc/self/exe" can resolve it on linux, you can try
> following patch.
Your patch contains an off by 2 error. So just try:
svn diff -c -951009 | patch -p0
to revert my change that broke it. (Although a small
part of that patch still makes sense - the basename part.)
> I'm not sure if it works on other platforms (AIX, z/OS).
It doesn't which is why I tried to make the change. I guess we do need
to handle it with platform specific #ifdefs.
Regards,
Mark.
Re: Problem met when building jdktools alone
Posted by Mark Hindess <ma...@googlemail.com>.
In message <20...@d12av03.megacenter.de.ibm.com>,
Mark Hindess writes:
>
> In message <AA...@mail.gmail.com>,
> Charles Lee writes:
> >
> > see this:
> > http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe
> >
> > It seems a little different on FreeBSD.
>
> I've reverted my change in r981763 so FreeBSD is already implemented.
> We need implementations for Aix and z/OS. Unless anyone has more
> specific AIX and/or z/OS implementations, then I think we should just
> fall back to a solution like main_get_executable_name from:
>
> classlib/modules/luni/src/main/native/launcher/unix/main_hlp.c
>
> However reading this code it has several issues - like the pointless
> directory changing in the !isSymbolicLink case and the use of
> readSymbolicLink when realpath would be more appropriate - so I'd rather
> fix it correctly then port the fixes back to the launcher (and portlib
> hysysinfo.c IIRC).
I also noticed that the main_hlp.c version searches the PATH by reading
the directory entries and doing string comparison. This seems like a
bad idea for several reasons:
1) It is slow
2) It doesn't check for execute permission so it can return the
incorrect answer in the case that a non-executable match is found before
the correct (executable match) later in the path.
r981763 fixed it for Linux. I've also committed r981820 that should fix
it for AIX and z/OS. Testing on those two platforms and review of the
new code would be very welcome. (I'll change the launcher version in a
few days time.)
Regards,
Mark.
Re: Problem met when building jdktools alone
Posted by Mark Hindess <ma...@googlemail.com>.
In message <AA...@mail.gmail.com>,
Charles Lee writes:
>
> see this:
> http://stackoverflow.com/questions/1023306/finding-current-executables-path-w
> ithout-proc-self-exe
>
> It seems a little different on FreeBSD.
I've reverted my change in r981763 so FreeBSD is already implemented.
We need implementations for Aix and z/OS. Unless anyone has more
specific AIX and/or z/OS implementations, then I think we should just
fall back to a solution like main_get_executable_name from:
classlib/modules/luni/src/main/native/launcher/unix/main_hlp.c
However reading this code it has several issues - like the pointless
directory changing in the !isSymbolicLink case and the use of
readSymbolicLink when realpath would be more appropriate - so I'd rather
fix it correctly then port the fixes back to the launcher (and portlib
hysysinfo.c IIRC).
Regards,
Mark.
> On Tue, Aug 3, 2010 at 10:24 AM, Regis <xu...@gmail.com> wrote:
>
> > On 2010-08-02 23:44, Daniel Gong wrote:
> >
> >> Hi all,
> >>
> >> As you know that I'm developing the jdb command line tool. I met a weird
> >> problem when building jdktools alone.
> >>
> >> Briefly, the problem is like this: after I build the jdktools module
> >> against
> >> hdk, each jdk tool command line tool turns out to be segmentation fault
> >> when
> >> running with a simple command such as "java", but succeeds when running
> >> with
> >> a full path such as "$HDK/jdk/bin/java".
> >>
> >> According to the component-wise instruction, I get the jdktools code and
> >> common resources code from svn, the directory structure is like this:
> >>
> >> myproject
> >> |
> >> |--------- jdktools
> >> | |
> >> | |---------- build.xml
> >> | |
> >> | |---------- LICENSE
> >> | |
> >> | |---------- make
> >> | |
> >> | |---------- modules
> >> | |
> >> | |---------- NOTICE
> >> |
> >> |--------- common resources
> >> | |
> >> | |---------- build.xml
> >> | |
> >> | |---------- depends
> >> | |
> >> | |---------- make
> >>
> >> And hdk is in another directory. HDK is also the java runtime that ant
> >> use.
> >>
> >> I have kept using the full path of jdk tool command to test whether my jdb
> >> works and tried to find a solution but still do not have one...
> >>
> >> Does any one know what happened? Thanks.
> >>
> >> Best wishes
> >> Daniel Gong
> >>
> >>
> > getExeDir in samsa.c uses realpath to find executable file path, which
> > can't handle case of executable file is in $PATH. Reading symbol link
> > "/proc/self/exe" can resolve it on linux, you can try following patch. I'm
> > not sure if it works on other platforms (AIX, z/OS).
> >
> > Index: jdktools/modules/samsa/src/main/native/samsa/samsa.c
> > =====================================================================
> > --- jdktools/modules/samsa/src/main/native/samsa/samsa.c
> > +++ jdktools/modules/samsa/src/main/native/samsa/samsa.c
> > @@ -471,13 +471,14 @@ char *getExeDir(const char* argv0) {
> >
> > // FIXME - handle this right - it could be that 512 isn't enough
> > #else
> > + int length;
> > char buffer[PATH_MAX + 1];
> >
> > - char *rc = realpath(argv0, buffer);
> > - if (!rc) {
> > - return NULL;
> > + length = readlink("/proc/self/exe", buffer, sizeof(buffer));
> > + if (length == -1) {
> > + return NULL;
> > }
> > - buffer[PATH_MAX] = '\0';
> > + buffer[length] = '\0';
> > #endif
> >
> > last = strrchr(buffer, PATH_SEPARATOR_CHAR);
> >
> >
> >
> > --
> > Best Regards,
> > Regis.
> >
>
>
>
> --
> Yours sincerely,
> Charles Lee
>
> --0015174beaa41f227f048ce43317--
>
Re: Problem met when building jdktools alone
Posted by Charles Lee <li...@gmail.com>.
see this:
http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe
It seems a little different on FreeBSD.
On Tue, Aug 3, 2010 at 10:24 AM, Regis <xu...@gmail.com> wrote:
> On 2010-08-02 23:44, Daniel Gong wrote:
>
>> Hi all,
>>
>> As you know that I'm developing the jdb command line tool. I met a weird
>> problem when building jdktools alone.
>>
>> Briefly, the problem is like this: after I build the jdktools module
>> against
>> hdk, each jdk tool command line tool turns out to be segmentation fault
>> when
>> running with a simple command such as "java", but succeeds when running
>> with
>> a full path such as "$HDK/jdk/bin/java".
>>
>> According to the component-wise instruction, I get the jdktools code and
>> common resources code from svn, the directory structure is like this:
>>
>> myproject
>> |
>> |--------- jdktools
>> | |
>> | |---------- build.xml
>> | |
>> | |---------- LICENSE
>> | |
>> | |---------- make
>> | |
>> | |---------- modules
>> | |
>> | |---------- NOTICE
>> |
>> |--------- common resources
>> | |
>> | |---------- build.xml
>> | |
>> | |---------- depends
>> | |
>> | |---------- make
>>
>> And hdk is in another directory. HDK is also the java runtime that ant
>> use.
>>
>> I have kept using the full path of jdk tool command to test whether my jdb
>> works and tried to find a solution but still do not have one...
>>
>> Does any one know what happened? Thanks.
>>
>> Best wishes
>> Daniel Gong
>>
>>
> getExeDir in samsa.c uses realpath to find executable file path, which
> can't handle case of executable file is in $PATH. Reading symbol link
> "/proc/self/exe" can resolve it on linux, you can try following patch. I'm
> not sure if it works on other platforms (AIX, z/OS).
>
> Index: jdktools/modules/samsa/src/main/native/samsa/samsa.c
> =====================================================================
> --- jdktools/modules/samsa/src/main/native/samsa/samsa.c
> +++ jdktools/modules/samsa/src/main/native/samsa/samsa.c
> @@ -471,13 +471,14 @@ char *getExeDir(const char* argv0) {
>
> // FIXME - handle this right - it could be that 512 isn't enough
> #else
> + int length;
> char buffer[PATH_MAX + 1];
>
> - char *rc = realpath(argv0, buffer);
> - if (!rc) {
> - return NULL;
> + length = readlink("/proc/self/exe", buffer, sizeof(buffer));
> + if (length == -1) {
> + return NULL;
> }
> - buffer[PATH_MAX] = '\0';
> + buffer[length] = '\0';
> #endif
>
> last = strrchr(buffer, PATH_SEPARATOR_CHAR);
>
>
>
> --
> Best Regards,
> Regis.
>
--
Yours sincerely,
Charles Lee
Re: Problem met when building jdktools alone
Posted by Regis <xu...@gmail.com>.
On 2010-08-02 23:44, Daniel Gong wrote:
> Hi all,
>
> As you know that I'm developing the jdb command line tool. I met a weird
> problem when building jdktools alone.
>
> Briefly, the problem is like this: after I build the jdktools module against
> hdk, each jdk tool command line tool turns out to be segmentation fault when
> running with a simple command such as "java", but succeeds when running with
> a full path such as "$HDK/jdk/bin/java".
>
> According to the component-wise instruction, I get the jdktools code and
> common resources code from svn, the directory structure is like this:
>
> myproject
> |
> |--------- jdktools
> | |
> | |---------- build.xml
> | |
> | |---------- LICENSE
> | |
> | |---------- make
> | |
> | |---------- modules
> | |
> | |---------- NOTICE
> |
> |--------- common resources
> | |
> | |---------- build.xml
> | |
> | |---------- depends
> | |
> | |---------- make
>
> And hdk is in another directory. HDK is also the java runtime that ant use.
>
> I have kept using the full path of jdk tool command to test whether my jdb
> works and tried to find a solution but still do not have one...
>
> Does any one know what happened? Thanks.
>
> Best wishes
> Daniel Gong
>
getExeDir in samsa.c uses realpath to find executable file path, which can't
handle case of executable file is in $PATH. Reading symbol link "/proc/self/exe"
can resolve it on linux, you can try following patch. I'm not sure if it works
on other platforms (AIX, z/OS).
Index: jdktools/modules/samsa/src/main/native/samsa/samsa.c
=====================================================================
--- jdktools/modules/samsa/src/main/native/samsa/samsa.c
+++ jdktools/modules/samsa/src/main/native/samsa/samsa.c
@@ -471,13 +471,14 @@ char *getExeDir(const char* argv0) {
// FIXME - handle this right - it could be that 512 isn't enough
#else
+ int length;
char buffer[PATH_MAX + 1];
- char *rc = realpath(argv0, buffer);
- if (!rc) {
- return NULL;
+ length = readlink("/proc/self/exe", buffer, sizeof(buffer));
+ if (length == -1) {
+ return NULL;
}
- buffer[PATH_MAX] = '\0';
+ buffer[length] = '\0';
#endif
last = strrchr(buffer, PATH_SEPARATOR_CHAR);
--
Best Regards,
Regis.