Mail Archives: cygwin/2006/05/24/08:10:16
On Wed, May 24, 2006 at 11:40:58AM +0100, Dave Korn wrote:
> > Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV
> > signal, correct? GDB does what it's told, stops on SIGSEGV by default.
> >
> > -cl
>
> But it doesn't interact properly with cygwin's exception handling -> signal
> mechanism, and the task dies, when it should just run on.
>
> Anyone who's doing any serious debugging on Cygwin very seriously wants to
> build their own gdb and insight from current CVS. It's much improved of late.
Right, or bless their sanity - as it won't last long. But I'm just trying to
debate that it's no "lacking" of gdb that it's catching SIGSEGV signals which
are being artificially generated by cygwin.
What's the design mechanism for the entire 'check for non-initialized space and
segfault if uninitialized' when it comes to statically initialized pthreads
objects in the first place, btw? Why not just have pthread_mutex_t (for example
actually be a pthread_mutex_t instead of it being a type'd pointer to the real
pthread_mutex_t? Why dynamically initialize space for it at all via the check
bunk memory->throw fault->alloc real memory for real pthread_mutex_t as opposed
to "initialiize the mutex->if bunk space, segfault as usual" ?
-cl
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -