From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: kevinb@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: Patches for GNU/Linux PPC native now in CVS Date: Thu, 24 Feb 2000 02:47:00 -0000 Message-ID: <200002241047.LAA02405@landau.wins.uva.nl> References: <1000222025201.ZM9805@ocotillo.lan> <200002221013.e1MAD3A00261@delius.kettenis.local> <1000224102541.ZM14031@ocotillo.lan> X-SW-Source: 2000-02/msg00004.html Message-ID: <20000224024700.NgwSQXZnC51jK39axfd1alZjgbDD0cyk3KFBYikH4YQ@z> Date: Thu, 24 Feb 2000 03:25:41 -0700 From: Kevin Buettner On Feb 22, 11:13am, Mark Kettenis wrote: [Detailed failure analysis snipped] > Anyway, I hope this helps, It did indeed. Thanks! (It showed me where not to focus my attention first.) I'll respond to the sourceware list when I've had more time to study your analysis, but in the meantime, I wanted to send you a note to let you know that I appreciated your analysis... Meanwhile, I learned something more about the gdb.base/annota1.exp: backtrace @ signal handler failure I reported. There is nothing wrong with the test per se. It's just that on my i586-pc-linux-gnu system the regexp matching takes an awful lot of time. Setting the timeout to 10 minutes made the test pass. This is probably related to the fact that with glibc there is an extra frame. Apparently the fix I suggested (but didn't understand), speeded up the regexp matching somewhat, but even in that case (with the default timeout) the test failed on my system last night. Sorry for the confusion. I just couldn't imagine the regexp matching taking the better part of 10 minutes :-(. Mark >From khendricks@ivey.uwo.ca Thu Feb 24 05:56:00 2000 From: Kevin Hendricks To: Kevin Buettner , khendricks@ivey.uwo.ca Cc: gdb@sourceware.cygnus.com Subject: Re: Patches for GNU/Linux PPC native now in CVS Date: Thu, 24 Feb 2000 05:56:00 -0000 Message-id: <00022408590700.29946@localhost.localdomain> References: <1000222025201.ZM9805@ocotillo.lan> <00022221542500.09439@localhost.localdomain> <1000224101226.ZM14012@ocotillo.lan> X-SW-Source: 2000-02/msg00005.html Content-length: 1523 Hi Kevin B. > > Everything was working fine until I decided to rerun the program > > from within gdb without removing my shared library breakpoints > > first. > > Does it work if you disable your shared library breakpoints first? I just tried it again (repeatedly) and I could not recreate the problem at all either way (with or without disabling breakpoints first). Now gdb just politely disables the breakpoints it can't enable in shared libraries and I just manually enable them later. So I think this problem is caused either by stack/memory corruption or some variable not being initialized properly. It seems to be quite random. I will keep playing with gdb and the jdk and let you know what is up. If it happens again, I will definitely try to get a pure c program that exhibits the same problems. > BTW, I just fixed one of the bugs (there were actually two separate bugs) > which was causing one of the shared library tests to fail. I'll commit > this fix later on today, but I doubt it will solve your problem. I will update my cvs tree tomorrow. Again thanks for all your help. I just need to play around with it some more under native threads to make sure some of the old problems have not cropped back up. Overall a very big improvement! Thanks, Kevin -- Kevin B. Hendricks Associate Professor of Operations and Information Technology Richard Ivey School of Business, University of Western Ontario London, Ontario N6A-3K7 CANADA khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959