Re: [Gc] a problem with msvc_dbg.c

Ivan Maidanski ivmai at mail.ru
Sun Mar 13 11:55:38 PST 2011


Hi Glauco,

I've fixed this (in a different way - similar to I had changed it for detect_GetWriteWatch one day).

Please the fetch the latest snapshot and test it.

Sun, 13 Mar 2011 17:47:42 +0100 письмо от "Glauco Masotti" <glauco.masotti at libero.it>:
> Hello again to everybody.
> 
> After the solution of the problem of 10 days ago, I took  the occasion of
> having the latest version compiled with 
> GC_DEBUG, to check my code for possible hidden errors.
> In fact there was one: I was getting a warning from the GC for the presence of
> a "smashed" object. This caused no 
> apparent malfunction, nevertheless it was alarming.
> If I haven't overlooked something, "smashed" objects (and how to deal with
> them) are not cited in the documentation, 
> however I assume that they become so because they are erroneously overwritten.
> So a combination of the techniques 
> suggested for other cases could be applied to catch them. Is this right?
> 
> Well, compiling the CG with: GC_DEBUG and KEEP_BACK_PTRS, I got the message:
> 
> GC_check_heap_block: found smashed heap objects:
> 00FE2EFC in or near object at 00FE2EA0(..\sources\nrutils.c:48, sz=88)
> 
> This was not enough to identify the object however, because I have many
> objects of that size.
> 
> Adding GC_ASSERTIONS and GC_PRINT_VERBOSE_STATS, in this case, is almost
> useless.
> 
> I was more positive with SAVE_CALL_CHAIN, but I had difficulties in compiling 
> msvc_dbg.c ('ULONG_PTR' : undeclared 
> identifier, etc.), which defines the required functions backtrace(..) and
> backtrace_symbols(..).
> Thus I modified the code, brutally defining:
> 
> typedef ULONG     ULONG_PTR ;
> 
> but perhaps something finer should be done.
> In any case it worked, and I got the call chain, thus identifying the exact
> object being overwritten. In fact its 
> allocation was incorrect, I had to increase its size by one element.
> 
> The author of msvc_dbg.c,  Andrei Polushin, or Hans himself, may want to
> re-look at the code in order to solve more 
> properly the compilation problems that I had. I am using VC++ 6.0 on a Win32
> machine with XP SP3 (still happy with this 
> old stuff :-).
> 
> Best regards,
> --- Glauco Masotti
> 
> 
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/



More information about the Gc mailing list