stop using mmap for zip I/O

[Andrew Haley]

On 02/27/2015 01:47 PM, Seán Coffey wrote:
> 
> On 27/02/15 12:23, christos at zoulas.com wrote:
>> On Feb 27,  9:51am, sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) wrote:
>> -- Subject: Re: stop using mmap for zip I/O
>>
>> | The sun.zip.disableMemoryMapping=true property helps with ZipFile class
>> | only. There are other related issues in the ZipInput/Output streams.
>> | Some code areas don't have synchronization and there are opportunities
>> | for the underlying native zip resources to be freed which Java code then
>> | tries to reference causing various SEGV. I've one or two areas of code
>> | identified for tightening up and hope to get to it in coming weeks.
>> | (long standing action item)
>>
>> Absolutely, there are unchecked lengths that are used to copy buffers...
> Are those issues documented in a bug report somewhere ? Please share if not.
> 
>> | > So we catch the signal, right?  Maybe there's something I'm missing...
>> | We don't catch/detect such SEGV's. Would it make sense, is it possible ?
>>
>> It is SIGBUS...
> The issues I've been looking at are SEGV issues concerning multiple threads
> operating on the same zip structure. (one freeing, while another is 
> attempting access)

The issue Christos is referring to is probably the bus error you get
when a buffer is unmapped.  This is what I was referring to as well.

Recovering from a crash caused by one thread modifying a structure
while another reads it is much harder; my apologies, I misunderstood
you.

Andrew.