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

[David Laight <david%l8s.co.uk@localhost>]

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??)

        David

-- 
David Laight: david%l8s.co.uk@localhost