[Gc] Re[2]: Avoid ABORT() in GC_log_printf

Boehm, Hans hans.boehm at hp.com
Tue Nov 20 12:45:25 PST 2012


Perhaps if the first WRITE fails, we should try printing something to GC_stderr, and if that also fails, we just forget about printing the log message?

I agree that this doesn’t justify an ABORT.

Hans

From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com] On Behalf Of Ivan Maidanski
Sent: Tuesday, November 20, 2012 12:16 PM
To: Kjetil Matheussen
Cc: gc at linux.hpl.hp.com
Subject: Re[2]: [Gc] Re[2]: Avoid ABORT() in GC_log_printf

Hi Kjetil,

Tue 20 Nov 2012 19:18:14 от Kjetil Matheussen <k.s.matheussen at notam02.no>:
Hi,

Maybe a configure option, like --ignore-abort, would be a good idea.
Also, I think it's quite drastic to call abort in GC_log_printf. The
message
I get from GC is this:

GC Warning: Repeated allocation of very large block (appr. size
397312):
May lead to memory leak and poor performance.

This is just a warning.
Add -DGC_IGNORE_WARN to your client app config for production.


I haven't tracked down why I get this warning, but it hasn't been
a problem, as far as I know. At least it shouldn't kill the program if
the output itself fails. It's quite common for applications to
run in a read-only directory.

Agree. I have no good idea how to improve this yet. (To say the truth, I don't like this win32 specific logging.)
I'll think about it. Ideas as usual are welcomed.


What about replacing

     if (WRITE(GC_log, buf, strlen(buf)) < 0)
       ABORT("write to log failed");

with

     GC_ASSERT(WRITE(GC_log, buf, strlen(buf) >= 0);

Definitely not correct because GC_ASSERT(x) expanded to no-op if not GC_ASSERTIONS.
But I got your idea which IMHO wrong because by design GC_ASSERT is assertion which violation signals a bug in the library (or the client).

PS. An alternative to create log file in the temporary folder might seem to be better than writing to the app folder but it has it's own pros.

Regards,
Ivan



On 20.11.2012 18:41, Ivan Maidanski wrote:
> Hi
>
> Ok, I see the problem but what are the solutions possible?
>
> Regards,
> Ivan
>
> Tue 20 Nov 2012 18:00:48 Kjetil Matheussen :
>
>> Hi Ivan,
>>
>> Thanks for quick reply!
>> And thanks for the tips!
>>
>> My target, when I got the error, was mingw32. I haven't seen
>> the same error when compiling for linux or osx. (But I don't
>> usually test those versions in a read-only directory either)
>>
>> > 3. By default, GC_log_printf write to stderr.
>>
>> That's strange, since it has generated this file:
>> -rw-rw-r-- 1 kjetil kjetil 120 2012-11-19 18:16 radium.bin.gc.log
>>
>> I cross compile my program using fedora 17, maybe something went
>> wrong when setting the default target for GC_log_printf.
>>
>> I'm pretty sure bdw-gc was compiled like this:
>> mingw32-configure && mingw32-make
>>
>> On 20.11.2012 16:59, Ivan Maidanski wrote:
>> > Hi Kjetil,
>> >
>> > 1. New abort function could be set via GC_set_abort_func.
>> > 2. You haven't specified your target.
>> > 3. By default, GC_log_printf write to stderr.
>> > 4. If you want to permanently ignore GC_log, you could pass
>> > -DGC_LOG_TO_FILE_ALWAYS -DGC_LOG_STD_NAME="/dev/null"
>> > 4. What should GC do in case of error?
>> >
>> > Regards,
>> > Ivan
>> >
>> > Tue 20 Nov 2012 16:25:48 Kjetil Matheussen :
>> >
>> >> Hi,
>> >>
>> >> I just got a crash which I think was caused by running my
>> program
>> >> in a
>> >> read-only directory.
>> >>
>> >> WRITE failed in GC_log_printf, and then ABORT() was called.
>> >>
>> >> Perhaps there is a configuration flag I can set which prevents
>> >> ABORT
>> >> from aborting?
>> >> (didn't find any though). I don't want the garbage collector to
>> >> abort
>> >> the program
>> >> in production code, even if it could be a serious error.
>> >>
>> >> I'll just redefine ABORT for now, but I think the default
>> behavior
>> >> needs to be changed.
>> >> (It could of course also be that I have misunderstood something)
>> >>
>> >> -Kjetil
>> >>
>> >> _______________________________________________
>> >> Gc mailing list
>> >> Gc at linux.hpl.hp.com<sentmsg?compose&To=Gc at linux.hpl.hp.com> [1] [1]
>> >> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/ [2] [2]
>> >
>> >
>> >
>> > Links:
>> > ------
>> > [1]
>> > http://www.eposttjener.no/sentmsg?compose
>> [3]&To=Gc at linux.hpl.hp.com
>> > [2] http://www.hpl.hp.com/hosted/linux/mail-archives/gc/ [4]
>
>
>
> Links:
> ------
> [1]
> http://www.eposttjener.no/sentmsg?compose|+|amp|+|To=Gc@linux.hpl.hp.com
> [2] http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> [3] http://www.eposttjener.no/sentmsg?compose
> [4] http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
Gc at linux.hpl.hp.com<sentmsg?compose&To=Gc at linux.hpl.hp.com>
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20121120/dec48bde/attachment-0001.htm


More information about the Gc mailing list