> "Jim" == Jim Meyering writes:
Jim> That is correct. It is a feature of gdb-7.0 and newer.
Jim> You can inspect (watch/break-at/etc.) the same address and expect it
Jim> to refer to the same memory location in multiple invocations.
Jim> This makes gdb's command-line history even more useful
Bruno Haible wrote:
> Rich Felker wrote:
>> The problem was an obscure pointer-arithmetic overflow ...
>> where the stack pointer is near the 4GB boundary.
>
> This explains also why it occurred only with a certain probability
> outside gdb, but with 100% probability from within gdb: Apparently gdb
Rich Felker wrote:
> The problem was an obscure pointer-arithmetic overflow ...
> where the stack pointer is near the 4GB boundary.
This explains also why it occurred only with a certain probability
outside gdb, but with 100% probability from within gdb: Apparently gdb
runs the program without add
On Tue, Jun 19, 2012 at 11:17:33PM +0200, Bruno Haible wrote:
> [...]
> The SIGSEGV occurs because d = 0x218b40 but the address ranges are these:
> 08048000-08049000 r-xp 08:05 26174991
> /data/bruno/tmp/testdir3/conftest
> 08049000-0804b000 rwxp 08:05 2
Rich Felker wrote:
> Do you have a dynamic-linked musl or just static?
Dynamically linked:
$ readelf -d conftest
Dynamic section at offset 0xf3c contains 18 entries:
TagType Name/Value
0x0001 (NEEDED) Shared library: [libc.so]
0x000
On Tue, Jun 19, 2012 at 10:04:57PM +0200, Bruno Haible wrote:
> I can reduce the program and the compilation options:
>
> === conftest.c =
> #include
> #include
> int main()
> {
> int ret;
> int err;
> ret = printf ("%.500f", 1.0)
Rich Felker wrote:
> > but once I get
> >
> > configure:8979: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2
> > -Wall conftest.c >&5
> > configure:8982: $? = 0
> > configure:8986: $? = 139
> > configure:9031: result: no
> >
> > So, apparently, under memory stress, musl's pr
On Tue, Jun 19, 2012 at 12:45:50PM +0200, Bruno Haible wrote:
> So, the exit code 1 must have come from the crash handler. Without this crash
> handler: 7x I get
>
> configure:8919: checking whether printf survives out-of-memory conditions
> configure:8979: /arch/x86-linux/inst-musl/bin/musl-g
Rich Felker wrote:
> > Replacements of *printf, because of
> > [...]
> > checking whether printf survives out-of-memory conditions... no
>
> No idea. Copying out the test and running it directly, it passes just
> fine for me. Maybe gnulib has already replaced printf with its own
> malloc-using v
