thank you so much, it was indeed a mid-way return that was causing this pblm.
regards, archana On Wed, 16 Jul 2003, Barry Bond wrote: > This assert means that there is a mismatch somewhere between PAL_TRY and > PAL_ENDTRY macros: if something within the PAL_TRY in your sample code > can do a 'return' or some other control flow change without executing > the code at PAL_ENDTRY, you'll see the assert. > > The best way to debug it is to put a breakpoint on your new PAL_TRY, and > when it hits, set breakpoints on PAL_EndTryHelper and PAL_TryHelper, > then see where the mismatch happens. Within the helpers, the > seh_info->bottom_frame points to a linked-list of active "try" blocks on > the stack and the assert indicates that the PAL_ENTRY is trying to > leave, but isn't the bottom-most node in the list. > > Barry > This posting is provided "AS IS" with no warranties, and confers no > rights. > > -----Original Message----- > From: Discussion of the Rotor Shared Source CLI implementation > [mailto:[EMAIL PROTECTED] On Behalf Of Archana > Sent: Wednesday, July 16, 2003 5:16 AM > To: [EMAIL PROTECTED] > Subject: [DOTNET-ROTOR] usage of PAL_TRY > > Hi, > in the process of making changes to the garbage collector, i added a > few > PAL_TRY blocks in gcsmp.cpp. of the following form > PAL_TRY { > .. > if(error) PAL_LEAVE_EX(labelxx); > } > PAL_EXCEPT_FILTER_EX(labelxx, HandleGCException, NULL) { > .. > } > PAL_ENDTRY > > but when i debug a simple application, i get the following Assert at the > first PAL_ENDTRY that i added.. > {0804D000} ASSERT [EXCEPT ] at ../exception.c.442: Exception > registration > pointers don't match! > > and if i comment all these it throws up the same assert at another > point, > in appdomain.cpp (SystemDomain::CreatePreallocatedExceptions) at the > COMPLUS_CATCH statement. > can you please help. > > Thanks and regards, > archana >
