On Thu, Aug 30, 2001 at 07:34:57AM +0200, Lourens Veen wrote: > Stephen Robert Norris wrote: > > > > I'd be interested to know how to avoid that. I'm pretty sure I can > > construct a scenario (with multiple threads and memory mapping, > > for example) where it's impossible to tell until you get the SEGV. For > > instance, I memory map a file, pass a pointer into the mapped > > region into the library and then unmap it some time later from another > > thread. > > > > Even if the library were checking (and I'm not sure how it could) that > > the pointer points to valid address space, there will be a time gap > > between the check and the use, and my unmapping can get in there. > > > > Having the library install its' own signal handler is not an acceptable > > solution, either. > > Well, call me stupid, but isn't that what mutexes are for? Thread 1 sets > the mutex, then calls the library with a pointer to some part of the > shared memory. Make sure thread 2 checks the mutex before unmapping and > there's no problem at all. > > Thing is, how is the library going to know whether the pointer is valid > or not? All the standard C functions that expect pointers will happily > write wherever you point them to, even if it causes a segfault. I don't > see how this is a problem with the library. If I divide by zero (which > is essentially calling the divide function with illegal values) I get an > exception as well. > > Lourens Yes, this is a way the application can avoid the problem; it's not a way the library can. My point was that it's impossible with modern OS's to avoid the possibility of the library crashing. Stephen -- Stephen Norris srn@xxxxxxxxx Farrow Norris Pty Ltd +61 417 243 239
