Re: [Gc] a problem with msvc_dbg.c
ivmai at mail.ru
Mon Mar 14 01:33:03 PST 2011
The latest version is available from bdwgc.sf.net
You can just get that msvc_dbg.c file on the portal or use an SVN client to fetch the snapshot.
Or, get it as a tar-ball from my site: https://ivmaisoft.com/_mirror/hpl/bdwgc-7_2alpha5-20110313.tar.tar.bz2
Mon, 14 Mar 2011 09:13:13 +0100 письмо от "Glauco Masotti" <glauco.masotti at libero.it>:
> Hi Ivan.
> The latest snapshot? Sorry, where do I get it?
> I am currently working with the latest available version from:
> --- Glauco
> ----- Original Message -----
> From: "Ivan Maidanski" <ivmai at mail.ru>
> To: "Glauco Masotti" <glauco.masotti at libero.it>; <gc at linux.hpl.hp.com>
> Sent: Sunday, March 13, 2011 8:55 PM
> Subject: Re: [Gc] a problem with msvc_dbg.c
> > 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 Ð¿Ð¸ÑÑOÐ¼Ð¾ Ð¾Ñ, "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
> >> 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
> >> 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
> >> 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
> >> 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
> >> machine with XP SP3 (still happy with this
> >> old stuff :-).
> >> Best regards,
> >> --- Glauco Masotti
> >> _______________________________________________
> >> Gc mailing list
> >> Gc at linux.hpl.hp.com
> >> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
More information about the Gc