From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <7e82960b744e04ccfb76f7a0f3161b94@rei2.9hal>
Date: Sat, 25 Aug 2012 12:54:14 +0200
From: cinap_lenrek@gmx.de
To: 9fans@9fans.net
In-Reply-To: <784EF005-8F40-41C0-8C43-3504CBE399C3@ar.aichi-u.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] dns
Topicbox-Message-UUID: af644ef4-ead7-11e9-9d60-3106f5b1d025

always make a process snapshot as the kernel might discard
your broken process once it runs low on memory so you have
time to debug:

snap 41356 >/tmp/dns.snap

char *domain strings alloc header seems to have been corrupted
(or just freed by accident?).

the string just gets allocated and freed in mydnsquery() so its
unlikely a bug there. someone else has corrupted its alloc header?

it looks more like corruption as we dont hand this pointer out to
someone else but netmkaddr().

look at the raw data, often one can get a clue by what it got
overridden with and try to figure out what the previous block
before our block that got corrupted was. the pool allocator keeps
the callerpc's of who allocated the block so you can use that
to figure out what it is, or look at the contents.

// dump the memory arround our corrupted block
dump(0x497f8 - 0x10, 0x100, "X")

maybe our block didnt got overridden but really freed with
a call to free but with the wrong pointer? check the alloc
magic!

// check the contents, should be an ip address string
dump(0x49800, 1, "s")

run acid with -lpool -lleak and run blockdump() if its
corrupted block, it might just stop at the block before
our one and will print the allocpc's and give some
diagnostics.

i can try this if you provide process snapshot file.

--
cinap