Re: Strange (or at least interesting) printf() behavior!

[christos%astron.com@localhost (Christos Zoulas)]

In article <20110225192751.GA14306%lynche.sis.pasteur.fr@localhost>,
Nicolas Joly  <njoly%pasteur.fr@localhost> wrote:
>-=-=-=-=-=-
>
>On Mon, Jan 03, 2011 at 06:22:39PM +0000, David Laight wrote:
>> On Mon, Jan 03, 2011 at 06:43:39PM +0100, Nicolas Joly wrote:
>> > 
>> > Program terminated with signal 6, Aborted.
>> > #0  0x00007f7ffd8e7dea in _lwp_kill () from /usr/lib/libc.so.12
>> > (gdb) bt
>> > #0  0x00007f7ffd8e7dea in _lwp_kill () from /usr/lib/libc.so.12
>> > #1  0x00007f7ffd8e775e in abort () at
>/local/src/NetBSD/src/lib/libc/stdlib/abort.c:74
>> > #2  0x0000000000400b58 in sigalrm_action (signo=14,
>info=0x7f7fffffc640, ptr=0x7f7fffffc6c0) at xx.c:23
>> > #3  <signal handler called>
>> > #4  0x00007f7ffd898f6e in arena_bin_run_size_calc
>(bin=0x7f7ffdff7110, min_run_size=<value optimized out>)
>> >     at /local/src/NetBSD/src/lib/libc/stdlib/jemalloc.c:2200
>> > #5  0x00007f7ffd89a4d1 in arenas_extend (ind=0) at
>/local/src/NetBSD/src/lib/libc/stdlib/jemalloc.c:2631
>> > #6  0x00007f7ffd89a9b4 in malloc_init_hard () at
>/local/src/NetBSD/src/lib/libc/stdlib/jemalloc.c:3655
>> > #7  0x00007f7ffd89bd35 in malloc (size=4096) at
>/local/src/NetBSD/src/lib/libc/stdlib/jemalloc.c:3313
>> 
>> That looks like the same place as the CTRL+C that gdb caught.
>> 
>> line 2200 of jmalloc is part of this test.
>>     } while (try_run_size <= arena_maxclass && try_run_size <= RUN_MAX_SMALL
>>      && max_ovrhd > RUN_MAX_OVRHD_RELAX / ((float)(bin->reg_size << 3))
>>      && ((float)(try_reg0_offset)) / ((float)(try_run_size)) > max_ovrhd);
>> 
>> So I guess it might be looping forever.
>> Maybe because of some unwanted FP state ??
>> 
>> (Actually that test can surely be revamped to avoid FP divisions??)
>
>Here it is ... patch for test/review. Got it from FreeBSD :
>
>revision 1.154
>date: 2007/12/18 05:27:57;  author: jasone;  state: Exp;  lines: +47 -42
>Use fixed point integer math instead of floating point math when
>calculating run sizes.  Use of the floating point unit was a potential
>pessimization to context switching for applications that do not otherwise
>use floating point math. [1]
>
>Reformat cpp macro-related comments to improve consistency.
>

Please commit it.

christos