HURP DURP LETS FREE A NULL POINTER.

As for the local arrays, JNI fixes it, or so the docs seemed to claim. I did
ask on the mailing list years ago when I coded it - I'm not an expert either.
No bad effects / leaks reported so far, though.

I will pay attention to random unjustified quoting of arbitrary "code styles"
when they give an accompanying reason and why it applies in this case. Here's
my counter: the jthrow macro is syntactic sugar that simulates a throw.

In any case, we should probably switch FEC libraries. It's disabled in 64 bit
due to that segfault issue (see mailing list archives) on certain inputs.

X

On 10/03/11 18:07, Matthew Toseland wrote:
>  Eleriseth at WPECGLtYbVi8Rl6Y7...
> Trust
>       Local   Peer
> Message               76
> Trust List            
>       Re: New freenet-ext.jar, please test! on 2011-03-10 14:07:05    
> [Permalink] Reply
> Disclaimer: I'm-not-JNI-expert.
> 
> toad-notrust at h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI wrote:
> We want to deploy this soon. Please test it.
> http://downloads.freenetproject.org/alpha/freenet-ext-v27pre8.jar
> 
> You can build this from the tag.
> 
> Potential memory leak on error path:
> 
> === cut fec/src/csrc/fec-jinterf.c ===
> #define malloc_jthrow(ENV, PTR, TYPE, NUM) \
> PTR = (TYPE *) malloc(sizeof(TYPE) * NUM); \
> if (PTR == NULL) { \
> (*ENV)->ThrowNew(ENV, (*ENV)->FindClass(ENV,
> "java/lang/OutOfMemoryError"), "malloc failed"); \
> return; \
> } \
> [...]
> /* allocate memory for the arrays */
> malloc_jthrow(env, inArr, jbyteArray, k);
> malloc_jthrow(env, retArr, jbyteArray, k);
> ^^ who is going to free inArr here?
> 
> malloc_jthrow(env, inarr, jbyte *, k);
> same: inArr, retArr
> malloc_jthrow(env, retarr, jbyte *, k);
> same: inArr, retArr, inarr
> [...]
> if ((*env)->PushLocalFrame(env, 3+k+numRet) < 0) {
> return; /* exception OutOfMemoryError */
> ^^ who is going to free *all* local arrays here?
> }
> [...]
> jref_null_check(localSrcOff);
> same here and a lot of similar code below
> [...]
> inarr[i] += localSrcOff[i];
> potential integer overflow (and out-of-array access)?
> === cut ===
> etc, etc, etc.
> BTW, general code style guides discourage using such
> macros-with-control-statements (goto, return,...).
> 
> 
> 
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl


-- 
GPG: 4096R/5FBBDBCE

Reply via email to