On 02/27/2015 01:47 PM, Seán Coffey wrote: > > On 27/02/15 12:23, chris...@zoulas.com wrote: >> On Feb 27, 9:51am, sean.cof...@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.
