| Message ID | 53D63F19.4050405@gmail.com |
|---|---|
| State | New |
| Headers | show |
Hello All: It is a simple way for finding these kinds of issues (issues may not be bugs), one sample for 'strncpy' (the same way for sprintf, strcpy, memcpy ...): - grep strncpy in all source code. - and then check each one by one. - at present, I have finish check about 30% for strncpy. Also have another ways for finding trivial patches (e.g. how to find resource leak when failure occurs, ...). If these kinds of trivial patches are only bother most of members, please let me know, and next, I shall not send this kinds of patches. Thanks. On 07/28/2014 08:16 PM, Chen Gang wrote: > 'errbuf' assumes itself will be zero terminated, and it also assumes > cpnative_getErrorString() may get larger length string than 'errbuf'. > So after strncpy(), 'errbuf' may not be zero terminated. > > strncpy() is sure of zero pad, but not be sure of zero terminated. > > > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> > --- > libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c b/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c > index a6076f2..0972a5e 100644 > --- a/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c > +++ b/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c > @@ -210,6 +210,7 @@ Java_java_lang_VMProcess_nativeSpawn (JNIEnv * env, jobject this, > if (err != 0) > { > strncpy(errbuf, cpnative_getErrorString (err), sizeof(errbuf)); > + errbuf[sizeof(errbuf) - 1] = '\0'; > goto system_error; > } > >
Hello All: I shall stop making this kind of patch, next. The reason is that I worry about what I have done have negative effect to others. And next, I shall try to send another kinds of patches for gcc when I have time. Many persons or companies use open source who never give thanks or contribution back to open source. But open source (especially, fundamental software) still provide common contributions to outside. What I have done is only for contribution back to open source, so I can understand none-reply from open source (at least, it is not the excuse to let myself stop). But what I worry about is whether bother others. Thanks. On 07/29/2014 01:29 PM, Chen Gang wrote: > Hello All: > > It is a simple way for finding these kinds of issues (issues may not be > bugs), one sample for 'strncpy' (the same way for sprintf, strcpy, > memcpy ...): > > - grep strncpy in all source code. > > - and then check each one by one. > > - at present, I have finish check about 30% for strncpy. > > Also have another ways for finding trivial patches (e.g. how to find > resource leak when failure occurs, ...). > > If these kinds of trivial patches are only bother most of members, > please let me know, and next, I shall not send this kinds of patches. > > > Thanks. > > On 07/28/2014 08:16 PM, Chen Gang wrote: >> 'errbuf' assumes itself will be zero terminated, and it also assumes >> cpnative_getErrorString() may get larger length string than 'errbuf'. >> So after strncpy(), 'errbuf' may not be zero terminated. >> >> strncpy() is sure of zero pad, but not be sure of zero terminated. >> >> >> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> >> --- >> libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c b/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c >> index a6076f2..0972a5e 100644 >> --- a/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c >> +++ b/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c >> @@ -210,6 +210,7 @@ Java_java_lang_VMProcess_nativeSpawn (JNIEnv * env, jobject this, >> if (err != 0) >> { >> strncpy(errbuf, cpnative_getErrorString (err), sizeof(errbuf)); >> + errbuf[sizeof(errbuf) - 1] = '\0'; >> goto system_error; >> } >> >> >
>>>>> "Chen" == Chen Gang <gang.chen.5i5j@gmail.com> writes:
Chen> 'errbuf' assumes itself will be zero terminated, and it also assumes
Chen> cpnative_getErrorString() may get larger length string than 'errbuf'.
Chen> So after strncpy(), 'errbuf' may not be zero terminated.
Chen> strncpy() is sure of zero pad, but not be sure of zero terminated.
It seems reasonable but Classpath patches should go upstream, to the
Classpath project.
Tom
>>>>> "Chen" == Chen Gang <gang.chen.5i5j@gmail.com> writes:
Chen> I shall stop making this kind of patch, next. The reason is that I worry
Chen> about what I have done have negative effect to others. And next, I shall
Chen> try to send another kinds of patches for gcc when I have time.
It's customary to wait a while before pinging patches, usually one or
two weeks. Reviewers are usually busy and don't spend all their time
reviewing.
Tom
On 07/30/2014 04:01 PM, Chen Gang wrote: > I shall stop making this kind of patch, next. The reason is that I worry > about what I have done have negative effect to others. And next, I shall > try to send another kinds of patches for gcc when I have time. > > Many persons or companies use open source who never give thanks or > contribution back to open source. But open source (especially, > fundamental software) still provide common contributions to outside. > > What I have done is only for contribution back to open source, so I can > understand none-reply from open source (at least, it is not the excuse > to let myself stop). But what I worry about is whether bother others. You only posted it yesterday. It certainly looks reasonable enough, but you surely don't expect an instant response. By the way, the correct mailing list is java-patches@gcc.gnu.org. Andrew.
On 07/30/2014 11:24 PM, Tom Tromey wrote: >>>>>> "Chen" == Chen Gang <gang.chen.5i5j@gmail.com> writes: > > Chen> I shall stop making this kind of patch, next. The reason is that I worry > Chen> about what I have done have negative effect to others. And next, I shall > Chen> try to send another kinds of patches for gcc when I have time. > > It's customary to wait a while before pinging patches, usually one or > two weeks. Reviewers are usually busy and don't spend all their time > reviewing. > Thank you very much for your reply in time. Next, I shall have a little patient (at least, wait 2 weeks or more). Thanks.
On 07/30/2014 11:32 PM, Andrew Haley wrote: > On 07/30/2014 04:01 PM, Chen Gang wrote: >> I shall stop making this kind of patch, next. The reason is that I worry >> about what I have done have negative effect to others. And next, I shall >> try to send another kinds of patches for gcc when I have time. >> >> Many persons or companies use open source who never give thanks or >> contribution back to open source. But open source (especially, >> fundamental software) still provide common contributions to outside. >> >> What I have done is only for contribution back to open source, so I can >> understand none-reply from open source (at least, it is not the excuse >> to let myself stop). But what I worry about is whether bother others. > > You only posted it yesterday. It certainly looks reasonable enough, > but you surely don't expect an instant response. By the way, the > correct mailing list is java-patches@gcc.gnu.org. > OK, thank you very much for your reply in time. And excuse me, originally, did not know about java-patches@gcc.gnu.org, next, I shall notice about it. At present, I guess: these kinds of patches are welcome in *@gcc.gnu.org, but I as a newbie need be familiar with the related working flow. Thanks.
On 07/30/14 09:01, Chen Gang wrote: > Hello All: > > I shall stop making this kind of patch, next. The reason is that I worry > about what I have done have negative effect to others. And next, I shall > try to send another kinds of patches for gcc when I have time. > > Many persons or companies use open source who never give thanks or > contribution back to open source. But open source (especially, > fundamental software) still provide common contributions to outside. > > What I have done is only for contribution back to open source, so I can > understand none-reply from open source (at least, it is not the excuse > to let myself stop). But what I worry about is whether bother others. I don't think you've have any kind of negative impact. GCC developers tend to be a bit more conservative and try not to change code just for the sake of changing code. Thus we tend to want to have a clearer understanding of why a particular change needs to be made. It's also the case that we tend to look more closely at patches from relatively new developers simply because we don't have a long history of interactions that have built trust over time. So, just to be clear, I don't think you're bothering anyone and I would recommend you continue to analyze code and send patches. And sorry for telling you everything goes to gcc-patches. I often forget there's a separate java patch list -- and more generally for the runtime libraries, we're often a downstream code consumer. Thus a proposed change in some of the runtime libraries may need to be sent to other projects (Classpath is a good example). jeff
On 07/31/2014 12:10 PM, Jeff Law wrote: > On 07/30/14 09:01, Chen Gang wrote: >> Hello All: >> >> I shall stop making this kind of patch, next. The reason is that I worry >> about what I have done have negative effect to others. And next, I shall >> try to send another kinds of patches for gcc when I have time. >> >> Many persons or companies use open source who never give thanks or >> contribution back to open source. But open source (especially, >> fundamental software) still provide common contributions to outside. >> >> What I have done is only for contribution back to open source, so I can >> understand none-reply from open source (at least, it is not the excuse >> to let myself stop). But what I worry about is whether bother others. > I don't think you've have any kind of negative impact. GCC developers > tend to be a bit more conservative and try not to change code just for > the sake of changing code. Thus we tend to want to have a clearer > understanding of why a particular change needs to be made. > > It's also the case that we tend to look more closely at patches from > relatively new developers simply because we don't have a long history of > interactions that have built trust over time. > > So, just to be clear, I don't think you're bothering anyone and I would > recommend you continue to analyze code and send patches. > OK, thank you for your encouragement. And I shall continue to send this kind of patches. > And sorry for telling you everything goes to gcc-patches. I often > forget there's a separate java patch list -- and more generally for the > runtime libraries, we're often a downstream code consumer. Thus a > proposed change in some of the runtime libraries may need to be sent to > other projects (Classpath is a good example). > OK, and I shall notice about it next time (send related patches to correct mailing list). For me, it will be good idea to have a related document for these mailing list intruduction (maybe it has, and I shall try to find it). Thanks.
Sorry for no testsuite, I shall send patch v2 for it after finish related testsuite within this week end (2014-08-03). And the patch v2 also need cc to java-patches@gcc.gnu.org Thanks. On 07/31/2014 12:59 PM, Chen Gang wrote: > > > On 07/31/2014 12:10 PM, Jeff Law wrote: >> On 07/30/14 09:01, Chen Gang wrote: >>> Hello All: >>> >>> I shall stop making this kind of patch, next. The reason is that I worry >>> about what I have done have negative effect to others. And next, I shall >>> try to send another kinds of patches for gcc when I have time. >>> >>> Many persons or companies use open source who never give thanks or >>> contribution back to open source. But open source (especially, >>> fundamental software) still provide common contributions to outside. >>> >>> What I have done is only for contribution back to open source, so I can >>> understand none-reply from open source (at least, it is not the excuse >>> to let myself stop). But what I worry about is whether bother others. >> I don't think you've have any kind of negative impact. GCC developers >> tend to be a bit more conservative and try not to change code just for >> the sake of changing code. Thus we tend to want to have a clearer >> understanding of why a particular change needs to be made. >> >> It's also the case that we tend to look more closely at patches from >> relatively new developers simply because we don't have a long history of >> interactions that have built trust over time. >> >> So, just to be clear, I don't think you're bothering anyone and I would >> recommend you continue to analyze code and send patches. >> > > OK, thank you for your encouragement. And I shall continue to send this > kind of patches. > >> And sorry for telling you everything goes to gcc-patches. I often >> forget there's a separate java patch list -- and more generally for the >> runtime libraries, we're often a downstream code consumer. Thus a >> proposed change in some of the runtime libraries may need to be sent to >> other projects (Classpath is a good example). >> > > OK, and I shall notice about it next time (send related patches to > correct mailing list). > > For me, it will be good idea to have a related document for these > mailing list intruduction (maybe it has, and I shall try to find it). > > > Thanks. >
Excuse me, after tried, I still did not know hot to build the source code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni". What I have done is: - ../gcc/configure --enable-core-jni --enable-languages=c,c++,java make all-target-libjava - also try "../gcc/configure && make", but get same result. - I also enable JNIDIRS in "x86_64-unknown-linux-gnu/libjava/classpath /native/jni/Makefile" manually, but still no effect. Welcome any ideas, suggestions or completions for it, thank. Also sorry, I did not finish sending patch v2 for it within 2014-08-03, one excuse is: for each complete building, it needs 12-15 hours under my laptop. So next, I shall buy a PC for it (also for linux kernel). Thanks. On 08/01/2014 01:19 PM, Chen Gang wrote: > > Sorry for no testsuite, I shall send patch v2 for it after finish > related testsuite within this week end (2014-08-03). > > And the patch v2 also need cc to java-patches@gcc.gnu.org > > Thanks. > > On 07/31/2014 12:59 PM, Chen Gang wrote: >> >> >> On 07/31/2014 12:10 PM, Jeff Law wrote: >>> On 07/30/14 09:01, Chen Gang wrote: >>>> Hello All: >>>> >>>> I shall stop making this kind of patch, next. The reason is that I worry >>>> about what I have done have negative effect to others. And next, I shall >>>> try to send another kinds of patches for gcc when I have time. >>>> >>>> Many persons or companies use open source who never give thanks or >>>> contribution back to open source. But open source (especially, >>>> fundamental software) still provide common contributions to outside. >>>> >>>> What I have done is only for contribution back to open source, so I can >>>> understand none-reply from open source (at least, it is not the excuse >>>> to let myself stop). But what I worry about is whether bother others. >>> I don't think you've have any kind of negative impact. GCC developers >>> tend to be a bit more conservative and try not to change code just for >>> the sake of changing code. Thus we tend to want to have a clearer >>> understanding of why a particular change needs to be made. >>> >>> It's also the case that we tend to look more closely at patches from >>> relatively new developers simply because we don't have a long history of >>> interactions that have built trust over time. >>> >>> So, just to be clear, I don't think you're bothering anyone and I would >>> recommend you continue to analyze code and send patches. >>> >> >> OK, thank you for your encouragement. And I shall continue to send this >> kind of patches. >> >>> And sorry for telling you everything goes to gcc-patches. I often >>> forget there's a separate java patch list -- and more generally for the >>> runtime libraries, we're often a downstream code consumer. Thus a >>> proposed change in some of the runtime libraries may need to be sent to >>> other projects (Classpath is a good example). >>> >> >> OK, and I shall notice about it next time (send related patches to >> correct mailing list). >> >> For me, it will be good idea to have a related document for these >> mailing list intruduction (maybe it has, and I shall try to find it). >> >> >> Thanks. >> >
On 8/3/14 13:50, Chen Gang wrote: > Excuse me, after tried, I still did not know hot to build the source > code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni". > What I have done is: > > - ../gcc/configure --enable-core-jni --enable-languages=c,c++,java > make all-target-libjava > > - also try "../gcc/configure && make", but get same result. > > - I also enable JNIDIRS in "x86_64-unknown-linux-gnu/libjava/classpath > /native/jni/Makefile" manually, but still no effect. > > Welcome any ideas, suggestions or completions for it, thank. > > Also sorry, I did not finish sending patch v2 for it within 2014-08-03, > one excuse is: for each complete building, it needs 12-15 hours under my > laptop. So next, I shall buy a PC for it (also for linux kernel). > After try again, I can let it pass building, but I do not know whether it is enough for this patch: - ../gcc/configure --enable-core-jni && make - enable JNIDIRS in x86_64-unknown-linux-gnu/libjava/classpath/native/ Makefile, manually. - then "make && make check" succeed with all related things are built. Before send patch v2 for it, I shall wait the confirmation from related members. Thanks.
I guess, I find the root cause:
In "gcc/libjava/configure", "--disable-core-jni" is hardcoded manually
for classpath with FIXME, then all related trying are useless. For me,
if have parameter "--enable-core-jni", need skip "--disable-core-jni".
The related information in gcc/libjava/configure:
6820 # Set up to configure Classpath.
6821 # FIXME: no supported way to pass args in autoconf.
6822 # Disable tool wrappers to avoid ltdl.h configure check.
6823 ac_configure_args="$ac_configure_args --disable-tool-wrappers"
6824 ac_configure_args="$ac_configure_args --disable-load-library"
6825 ac_configure_args="$ac_configure_args --${LIBGCJDEBUG}-debug"
6826 ac_configure_args="$ac_configure_args --enable-default-toolkit=$TOOLKIT"
6827 dir1=`cd $srcdir && pwd`
6828 dir2=`pwd`
6829 ac_configure_args="$ac_configure_args --with-vm-classes=$dir1:$dir2"
6830 ac_configure_args="$ac_configure_args --disable-core-jni"
6831 ac_configure_args="$ac_configure_args --disable-examples"
6832 ac_configure_args="$ac_configure_args --with-glibj=build"
On 08/10/2014 01:58 PM, Chen Gang wrote:
>
> On 8/3/14 13:50, Chen Gang wrote:
>> Excuse me, after tried, I still did not know hot to build the source
>> code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni".
>> What I have done is:
>>
>> - ../gcc/configure --enable-core-jni --enable-languages=c,c++,java
>> make all-target-libjava
>>
>> - also try "../gcc/configure && make", but get same result.
>>
>> - I also enable JNIDIRS in "x86_64-unknown-linux-gnu/libjava/classpath
>> /native/jni/Makefile" manually, but still no effect.
>>
>> Welcome any ideas, suggestions or completions for it, thank.
>>
>> Also sorry, I did not finish sending patch v2 for it within 2014-08-03,
>> one excuse is: for each complete building, it needs 12-15 hours under my
>> laptop. So next, I shall buy a PC for it (also for linux kernel).
>>
>
> After try again, I can let it pass building, but I do not know whether
> it is enough for this patch:
>
> - ../gcc/configure --enable-core-jni && make
>
> - enable JNIDIRS in x86_64-unknown-linux-gnu/libjava/classpath/native/
> Makefile, manually.
>
> - then "make && make check" succeed with all related things are built.
>
> Before send patch v2 for it, I shall wait the confirmation from related
> members.
>
>
> Thanks.
>
On 08/10/2014 04:22 PM, Chen Gang wrote: > > I guess, I find the root cause: > Although I say "I guess", in fact, I already had related proofs for it. - When configure "libjava/classpath", "--disable-core-jni" is passed as parameter explicitly (can check "x86_64-.../libjava/classpatch/ config.log" to know about it). - if pass "--disable-core-jni" to "libjava/classpatch/configure", it will disable 'JNIDIR' in "libjava/classpath/native/jni/Makefile". If remove "--disable-core-jni", it enables 'JNIDIR' to build java-lang. - After grep "--disaboe-core-jni", only "libjava/configure(.ac)" do it (and hard code it). For me, the proofs are enough, and the code in "libjava/configure(.ac)" are also obvious for it. So please check it is whether it is the root cause, when you have time. Thanks. > In "gcc/libjava/configure", "--disable-core-jni" is hardcoded manually > for classpath with FIXME, then all related trying are useless. For me, > if have parameter "--enable-core-jni", need skip "--disable-core-jni". > > The related information in gcc/libjava/configure: > > 6820 # Set up to configure Classpath. > 6821 # FIXME: no supported way to pass args in autoconf. > 6822 # Disable tool wrappers to avoid ltdl.h configure check. > 6823 ac_configure_args="$ac_configure_args --disable-tool-wrappers" > 6824 ac_configure_args="$ac_configure_args --disable-load-library" > 6825 ac_configure_args="$ac_configure_args --${LIBGCJDEBUG}-debug" > 6826 ac_configure_args="$ac_configure_args --enable-default-toolkit=$TOOLKIT" > 6827 dir1=`cd $srcdir && pwd` > 6828 dir2=`pwd` > 6829 ac_configure_args="$ac_configure_args --with-vm-classes=$dir1:$dir2" > 6830 ac_configure_args="$ac_configure_args --disable-core-jni" > 6831 ac_configure_args="$ac_configure_args --disable-examples" > 6832 ac_configure_args="$ac_configure_args --with-glibj=build" > > > > On 08/10/2014 01:58 PM, Chen Gang wrote: >> >> On 8/3/14 13:50, Chen Gang wrote: >>> Excuse me, after tried, I still did not know hot to build the source >>> code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni". >>> What I have done is: >>> >>> - ../gcc/configure --enable-core-jni --enable-languages=c,c++,java >>> make all-target-libjava >>> >>> - also try "../gcc/configure && make", but get same result. >>> >>> - I also enable JNIDIRS in "x86_64-unknown-linux-gnu/libjava/classpath >>> /native/jni/Makefile" manually, but still no effect. >>> >>> Welcome any ideas, suggestions or completions for it, thank. >>> >>> Also sorry, I did not finish sending patch v2 for it within 2014-08-03, >>> one excuse is: for each complete building, it needs 12-15 hours under my >>> laptop. So next, I shall buy a PC for it (also for linux kernel). >>> >> >> After try again, I can let it pass building, but I do not know whether >> it is enough for this patch: >> >> - ../gcc/configure --enable-core-jni && make >> >> - enable JNIDIRS in x86_64-unknown-linux-gnu/libjava/classpath/native/ >> Makefile, manually. >> >> - then "make && make check" succeed with all related things are built. >> >> Before send patch v2 for it, I shall wait the confirmation from related >> members. >> >> >> Thanks. >> >
On 8/12/14 4:20, Chen Gang wrote: > On 08/10/2014 04:22 PM, Chen Gang wrote: >> >> I guess, I find the root cause: >> I have given the test, if remove the hardcoded "--disable-core-jni" from libjava/configure, we can let "JNIDIR" enabled. So I am sure, it must be the root cause. Thanks. > > Although I say "I guess", in fact, I already had related proofs for it. > > - When configure "libjava/classpath", "--disable-core-jni" is passed > as parameter explicitly (can check "x86_64-.../libjava/classpatch/ > config.log" to know about it). > > - if pass "--disable-core-jni" to "libjava/classpatch/configure", it > will disable 'JNIDIR' in "libjava/classpath/native/jni/Makefile". If > remove "--disable-core-jni", it enables 'JNIDIR' to build java-lang. > > - After grep "--disaboe-core-jni", only "libjava/configure(.ac)" do it > (and hard code it). > > For me, the proofs are enough, and the code in "libjava/configure(.ac)" > are also obvious for it. > > > So please check it is whether it is the root cause, when you have time. > > Thanks. > >> In "gcc/libjava/configure", "--disable-core-jni" is hardcoded manually >> for classpath with FIXME, then all related trying are useless. For me, >> if have parameter "--enable-core-jni", need skip "--disable-core-jni". >> >> The related information in gcc/libjava/configure: >> >> 6820 # Set up to configure Classpath. >> 6821 # FIXME: no supported way to pass args in autoconf. >> 6822 # Disable tool wrappers to avoid ltdl.h configure check. >> 6823 ac_configure_args="$ac_configure_args --disable-tool-wrappers" >> 6824 ac_configure_args="$ac_configure_args --disable-load-library" >> 6825 ac_configure_args="$ac_configure_args --${LIBGCJDEBUG}-debug" >> 6826 ac_configure_args="$ac_configure_args --enable-default-toolkit=$TOOLKIT" >> 6827 dir1=`cd $srcdir && pwd` >> 6828 dir2=`pwd` >> 6829 ac_configure_args="$ac_configure_args --with-vm-classes=$dir1:$dir2" >> 6830 ac_configure_args="$ac_configure_args --disable-core-jni" >> 6831 ac_configure_args="$ac_configure_args --disable-examples" >> 6832 ac_configure_args="$ac_configure_args --with-glibj=build" >> >> >> >> On 08/10/2014 01:58 PM, Chen Gang wrote: >>> >>> On 8/3/14 13:50, Chen Gang wrote: >>>> Excuse me, after tried, I still did not know hot to build the source >>>> code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni". >>>> What I have done is: >>>> >>>> - ../gcc/configure --enable-core-jni --enable-languages=c,c++,java >>>> make all-target-libjava >>>> >>>> - also try "../gcc/configure && make", but get same result. >>>> >>>> - I also enable JNIDIRS in "x86_64-unknown-linux-gnu/libjava/classpath >>>> /native/jni/Makefile" manually, but still no effect. >>>> >>>> Welcome any ideas, suggestions or completions for it, thank. >>>> >>>> Also sorry, I did not finish sending patch v2 for it within 2014-08-03, >>>> one excuse is: for each complete building, it needs 12-15 hours under my >>>> laptop. So next, I shall buy a PC for it (also for linux kernel). >>>> >>> >>> After try again, I can let it pass building, but I do not know whether >>> it is enough for this patch: >>> >>> - ../gcc/configure --enable-core-jni && make >>> >>> - enable JNIDIRS in x86_64-unknown-linux-gnu/libjava/classpath/native/ >>> Makefile, manually. >>> >>> - then "make && make check" succeed with all related things are built. >>> >>> Before send patch v2 for it, I shall wait the confirmation from related >>> members. >>> >>> >>> Thanks. >>> >> > >
diff --git a/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c b/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c index a6076f2..0972a5e 100644 --- a/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c +++ b/libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c @@ -210,6 +210,7 @@ Java_java_lang_VMProcess_nativeSpawn (JNIEnv * env, jobject this, if (err != 0) { strncpy(errbuf, cpnative_getErrorString (err), sizeof(errbuf)); + errbuf[sizeof(errbuf) - 1] = '\0'; goto system_error; }
'errbuf' assumes itself will be zero terminated, and it also assumes cpnative_getErrorString() may get larger length string than 'errbuf'. So after strncpy(), 'errbuf' may not be zero terminated. strncpy() is sure of zero pad, but not be sure of zero terminated. Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> --- libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c | 1 + 1 file changed, 1 insertion(+)