Hmmh, I thought we had a little helper-routine to check memory-validity before dereferencing a pointer, but I seem to be mixing up the (old) kernel unwinder with the one based on libunwind. Maybe your problem will convince everybody that the libunwind-based unwinder should be merged into mainline? ;-) I posted the patch a couple of months ago to the kernel list. Probably it would need to be freshened-up a bit. Tony, what do you think? --david On 5/17/07, Robin Holt <holt@xxxxxxx> wrote:
On Thu, May 17, 2007 at 08:16:55AM -0600, David Mosberger-Tang wrote: > On 5/17/07, Keith Owens <kaos@xxxxxxx> wrote: > > >David Mosberger > >reckons that unwind should never cause an error, maybe we should be > >looking at adding more checks to the unwind code to cope with spurious > >addresses? > > That's correct. If the unwinder causes MCAs, it's broken. Robin, can > you look into why the memory-access safety-checks in the unwinder > aren't sufficient to avoid the MCAs you're seeing? I don't think it got very far at all. The task in question is calling get_wchan on itself. It is at >> px *(task_struct *)0xe003819a00000000 | grep ksp ksp = 0xe003819a00007900 >> px 0xe003819a00007900 + 16 0xe003819a00007910 >> px *(switch_stack *)0xe003819a00007910 | grep bsp ar_bspstore = 0xe003819a00000000 Here we start to run into difficulties. ar_bspstore is the same address as our task_struct. info->regstk.top == 0xe003819a00000000 which leads to unw_init_frame_info calculating info->bsp == 0xe0038199ffffff30 which is near the addresses causing problems (0xe0038199ffffff80 and 0xe0038199ffffffe0). Notice it is in the page before our task_struct. Well, time for bed. Thanks, Robin
-- Mosberger Consulting LLC, http://www.mosberger-consulting.com/ - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |