From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Kenji Arisawa In-Reply-To: <7e82960b744e04ccfb76f7a0f3161b94@rei2.9hal> Date: Sat, 25 Aug 2012 21:37:05 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <7e82960b744e04ccfb76f7a0f3161b94@rei2.9hal> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] dns Topicbox-Message-UUID: af68876c-ead7-11e9-9d60-3106f5b1d025 Hello cinap, broken dns triggers Fauth problem, so I have rebooted. I will get snapshot at next crash. Kenji Arisawa On 2012/08/25, at 19:54, cinap_lenrek@gmx.de wrote: > 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 >