RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

Roger Riggs roger.riggs at oracle.com
Thu Oct 29 23:22:22 UTC 2015


Hi Mandy,

Collapsing the emails.

As for asserting that module name is never null;
it appears that the module name is not being supplied by the VM. (in 
hs-comp or jdk9).

On 10/29/15 12:59 PM, Mandy Chung wrote:
>> On Oct 27, 2015, at 11:40 PM, Roger Riggs <roger.riggs at oracle.com> wrote:
>>
>> Please review an update to the jimage reader implementation to correct the
>> case where a class name is very long causing a SEGV due to buffer overruns.
>>
>> The fix will be pushed to the hs-comp repo; the bug was first spotted there.
> I suggest to push it to jdk9/dev and that will be pulled into hs-comp when it’s sync’ed up.
ok, the issue was with HS tests failing and pushing to hs-comp more 
rapidly addresses that.
But I'm fine with pushing to jdk9.

(BTW, there is a different fix for this issue expected to be 
reimplemented for Jake).
>
>> Webrev:
>>    http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390
> Looks okay in general.
>
> ImageNativeSubstrate.cpp
>      Is this native JIMAGE_FindResource method intended for tests to use?  I don’t find any reference to it besides tests.  The other option is to have a java method checking null parameters and call this native method (and make this native method private).
yes, it is only being used to specifically test the native JIMAGE_xxx 
native functions.
>
> test/jdk/internal/jimage/JImageReadTest.java
> 169         Assert.assertTrue(max > 16000,
> 170                 "missing entries, should be more than 31000, reported: " + count);
>
> Is the change from 31000 to 16000 accidental?
When I added a test for a long classname, I discovered that the test was 
not properly marked with @test
and was not being run.  When I re-enabled it, I observed that the number 
of entries
was quite a bit smaller than previously and so updated the test.
>
> This is unrelated to your change and just to mention it.  The test hardcodes 9.0 as the version and the hardcoded value should be replaced for future release.   Probably best to file a JBS issue for that.
I thought I had seen a change to allow a default version to be used.  
But at the moment the
argument is ignored and until it is not ignored this value is immaterial.

Thanks, Roger

>
> Mandy



More information about the jigsaw-dev mailing list