Date: Thu, 12 Jul 2001 10:50:06 -0700 (PDT) From: "Dorr H. Clark" <dclark@applmath.scu.edu> To: freebsd-hackers@freebsd.org Subject: now OK, was - need help: gdb -k 4.16/7 Message-ID: <Pine.GHP.4.21.0107121037190.26230-100000@hpux37.dc.engr.scu.edu>
next in thread | raw e-mail | index | archive | help
Some time ago, I wrote: > I am experimenting with porting an application > from the FreeBSD 2.2.x series to a more modern release, > and as such I have occaision to debug kernel core files > under the old release using the gdb -k option > (saved via savecore). The problem is the old kernel > has been customized with a different load address > (new style 0xC0000000 vs. old style 0xF0000000). > ... The problem is the resulting gdb -k sessions > are not fully functional... 80% of all problems that appear to be OS problems are really application problems. This was one of them. It turns out that there were more changes than just the load address, the application malloc() calls in the custom kernel had also been changed from 512, 1k, & 2k (sub-page fragments) to full page allocations (actually multi-page). As you may know, FreeBSD malloc()s of sub-page fragments in the kernel are permanent, when they are freed they are put on queues according to size buckets. In contrast, freeing multiple whole pages truly frees the pages, including unmapping! So when the kernel went down, the at_shutdown() call was freeing all the memory, and unmapping it. This side effect was never noticed in the old system, the debugging of cores was actually relying on the stale mapping of freed memory (I didn't do this code myself, so I didn't catch it before). The fix was only to free() in in the at_shutdown() call IF a normal shutdown is in progress (i.e.- not a panic, page_fault, etc.). I just wanted to share the absolution of the product for the permanent record. The custom FreeBSD kernel is doing the Right Thing (tm), gdb is doing the Right Thing (tm), savecore and wddump() are doing the Right Thing (tm), and when the application code is doing the right thing the cores are completely debuggable. Thanks for the previous responses, it was helpful in straightening this bug out, -Dorr H. Clark Santa Clara University To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GHP.4.21.0107121037190.26230-100000>