[Bug translator/14820] New: hang when running semok/nodwf01.stp

[dsmith at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14820

             Bug #: 14820
           Summary: hang when running semok/nodwf01.stp
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap@sourceware.org
        ReportedBy: dsmith@redhat.com
    Classification: Unclassified


When running the semok/nodwf01.stp testcase, systemtap will hang on
2.6.32-279.5.2.el6.x86_64.

That test does:

# stap -p2 --ignore-vmlinux --kmap=/proc/kallsyms -e '{SCRIPT}'

I've debugged this a bit with gdb. It appears that stap goes into an infinite
loop in module_info::update_symtab() (from tapsets.cxx), which looks like this:

====
void
module_info::update_symtab(cu_function_cache_t *funcs)
{
  if (!sym_table)
    return;

  cu_function_cache_t new_funcs;

  for (cu_function_cache_t::iterator func = funcs->begin();
       func != funcs->end(); func++)
    {
      // optimization: inlines will never be in the symbol table
      if (dwarf_func_inline(&func->second) != 0)
        continue;

      // XXX We may want to make additional efforts to match mangled elf names
      // to dwarf too.  MIPS_linkage_name can help, but that's sometimes
      // missing, so we may also need to try matching by address.  See also the
      // notes about _Z in dwflpp::iterate_over_functions().

      func_info *fi = sym_table->lookup_symbol(func->first);
      if (!fi)
        continue;

      // iterate over all functions at the same address
      symbol_table::range_t er = sym_table->map_by_addr.equal_range(fi->addr);
      for (symbol_table::iterator_t it = er.first; it != er.second; ++it)
        {
          // update this function with the dwarf die
          it->second->die = func->second;

          // if this function is a new alias, then
          // save it to merge into the function cache
          if (it->second != fi)
            new_funcs.insert(make_pair(it->second->name, it->second->die));
        }
    }

  // add all discovered aliases back into the function cache
  // NB: this won't replace any names that dwarf may have already found
  funcs->insert(new_funcs.begin(), new_funcs.end());
}
====

stap happily runs through around 660 symbols, then hits the
"shrink_dcache_memory" symbol. When that symbol is processed, stap never breaks
out of that innermost 'for' loop (the one with the "iterate over all functions
at the same address" comment).

In my current run, I've been stuck there for over an hour. I've let this test
run overnight, and it never finishes on this system.

Note that this is being run on actual hardware, not on a vm. Also this system
only has 1M of memory (however only about 1/2 of swap has been consumed at this
point).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.