Re[2]: Fwd: [Gc] Can not print call chain

Ivan Maidanski ivmai at mail.ru
Wed Jun 30 22:38:45 PDT 2010


Wed, 30 Jun 2010 21:36:25 +0000 "Boehm, Hans" <hans.boehm at hp.com>:

> Just catching up on email.  Hopefully this will make it to the list.  Sorry about the problem.  Please continue to send mail to me directly if you encounter such a problem again. 
> 
> For the smallest possible footprint, I would use -DSMALL_CONFIG ...

Yes, it might worth but there is a possibility of running out of heap sections (on Win32), so it might be needed to also specify -DMAX_HEAP_SECTS=<some_value) (e.g. 512).

> ... and not mention PARALLEL_MARK or THREAD_LOCAL_ALLOC.

Yes (unless, probably, you are targeting a multicore CPU device).

As for USE_MUNMAP, I found it useful when it's unknown how much memory your app eats and the app calls OS API functions that might eat OS memory (e.g. if an OS call fails with the not enough memory reason then you can call GC_gcollect_and_unmap and retry).

> 
> I second Ivan's question about whether GC_DEBUG was defined and allocation was done through the (all uppercase) macros.
> 
> Hans
> 
> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai at mail.ru] 
> Sent: Monday, June 21, 2010 1:26 AM
> To: Boehm, Hans
> Subject: Fwd: Re: [Gc] Can not print call chain
> 
> Hello, Hans!
> 
> I've forwarded this letter to you because I got the following from gc at linux.hpl.hp.com:
>     SMTP error from remote mailer after end of data:
>     host mail-ext.hpl.hp.com [192.6.19.124]: 554 5.7.1 No spam wanted here.
> 
> 
> Mon, 21 Jun 2010 12:10:26 +0400 Ivan Maidanski <ivmai at mail.ru>:
> 
> > 
> > Mon, 21 Jun 2010 07:14:33 +0000 (UTC) biosli <biosli at hotmail.com>:
> > 
> > > Hi, all.
> > > 
> > > I download new GC package (last changed 2010-5-31), and build it 
> > > under windows with define "SAVE_CALL_CHAIN" and "SAVE_CALL_COUNT 8".
> > > 
> > > Then I set GC_find_leak as 1 in my program.
> > > 
> > > But GC not print the call chain as old version, just print a header 
> > > of leak info, as below:
> > > 
> > > Leaked atomic object at start: 01C9DFA8, appr. length: 72 Leaked 
> > > composite object at start: 01C81C00, appr. length: 48 Leaked 
> > > composite object at start: 01C81C30, appr. length: 48 Leaked 
> > > composite object at start: 01C81C60, appr. length: 48
> > > 
> > > I want to show the call chain. what should i do?
> > 
> > AICS, in GC_debug_print_heap_obj_proc(), GC_default_print_heap_obj_proc(p) is called instead of GC_print_obj(p). PRINT_CALL_CHAIN() is called only from GC_print_obj.
> > 
> > Did you define GC_DEBUG in your client?
> > 
> > Hans should know better the situation.
> > 
> > > 
> > > And I use GC in my program, which under Windows Mobile(WinCE) 
> > > platform, it only have 20 MB memory for each process. What build definition I should add?
> > 
> > For VS2008, I use the following (also add -DVERY_SMALL_CONFIG for test.c):
> > 
> > cl -MT -DALL_INTERIOR_POINTERS -DNO_DEBUGGING -DGC_THREADS 
> > -DGC_READ_ENV_FILE -I.\include -I.\libatomic_ops\src -DUSE_MUNMAP 
> > -DTHREAD_LOCAL_ALLOC -DPARALLEL_MARK -DUNICODE -DUNDER_CE 
> > -D_WIN32_WCE=0x0300 -D_ARM_ -DARM -c *.c *.cpp
> > 
> > For mingw32ce/arm, I use:
> > gcc -fno-strict-aliasing -Wall -DALL_INTERIOR_POINTERS -DNO_DEBUGGING 
> > -DGC_THREADS -DGC_READ_ENV_FILE -I include -I libatomic_ops/src 
> > -DUSE_MUNMAP -DTHREAD_LOCAL_ALLOC -DPARALLEL_MARK -c *.c *.cpp
> > 
> > > 
> > > Thanks all your help.



More information about the Gc mailing list