Bug 158555 - Helgrind: program has too many thread sets or lock sets to track
Summary: Helgrind: program has too many thread sets or lock sets to track
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: helgrind (show other bugs)
Version: 3.4 SVN
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-28 23:16 UTC by Chris Moore
Modified: 2009-06-29 08:56 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Moore 2008-02-28 23:16:51 UTC
On Ubuntu 7.10, using SVN trunk r7497.  I tried loading a big input file (
http://svn.voria.com/code/synfig-core/trunk/examples/pirates.sifz ) into Synfig
Studio ( http://synfig.org/ ).

helgrind crashed.  It told me:

  Note: see also the FAQ.txt in the source distribution.
  It contains workarounds to several common problems.

but I don't have any FAQ.txt file.

The output was:

Helgrind: Fatal internal error -- cannot continue.
Helgrind: mk_SHVAL_ShR(tset=19,lset=356247): FAILED
Helgrind: max allowed tset=8191, lset=131071
Helgrind: program has too many thread sets or lock sets to track.

Helgrind: hg_main.c:926 (mk_SHVAL_fail): the 'impossible' happened.
==12263==    at 0x3801B8DD: report_and_quit (m_libcassert.c:140)
==12263==    by 0x3801BBE1: vgPlain_assert_fail (m_libcassert.c:200)
==12263==    by 0x38005C53: mk_SHVAL_fail (hg_main.c:926)
==12263==    by 0x3800D3D0: msm__handle_read (hg_main.c:944)
==12263==    by 0x3800E772: evh__mem_help_read_4 (hg_main.c:4359)
==12263==    by 0x63909AB9: ???
==12263==    by 0x38BD1F4B: temporary (in
/home/chris/programs/valgrind/trunk/install/lib/valgrind/x86-linux/helgrind)
==12263==    by 0x8: ???

sched status:
  running_tid=2

Thread 1: status = VgTs_WaitSys
==12263==    at 0x40007F2: (within /lib/ld-2.6.1.so)
==12263==    by 0x5555534: (within /lib/tls/i686/cmov/libc-2.6.1.so)
==12263==    by 0x555586E: _IO_do_write (in /lib/tls/i686/cmov/libc-2.6.1.so)
==12263==    by 0x5556178: _IO_file_overflow (in /lib/tls/i686/cmov/libc-2.6.1.so)
==12263==    by 0x555572D: _IO_file_xsputn (in /lib/tls/i686/cmov/libc-2.6.1.so)
==12263==    by 0x552FD57: vfprintf (in /lib/tls/i686/cmov/libc-2.6.1.so)
==12263==    by 0x5538942: printf (in /lib/tls/i686/cmov/libc-2.6.1.so)
==12263==    by 0x837DB43: studio::AsyncRenderer::start_() (asyncrenderer.cpp:520)
==12263==    by 0x837FBDE: sigc::bound_mem_functor0<void,
studio::AsyncRenderer>::operator()() const (mem_fun.h:1787)
==12263==    by 0x837FBF5: sigc::adaptor_functor<sigc::bound_mem_functor0<void,
studio::AsyncRenderer> >::operator()() const (adaptor_trait.h:251)
==12263==    by 0x837FC0B: sigc::bind_return_functor<bool,
sigc::bound_mem_functor0<void, studio::AsyncRenderer> >::operator()()
(bind_return.h:173)
==12263==    by 0x837FC3B:
sigc::internal::slot_call0<sigc::bind_return_functor<bool,
sigc::bound_mem_functor0<void, studio::AsyncRenderer> >,
bool>::call_it(sigc::internal::slot_rep*) (slot.h:103)
==12263==    by 0x4FC5387: (anonymous namespace)::glibmm_source_callback(void*)
(slot.h:440)
==12263==    by 0x53408D5: (within /usr/lib/libglib-2.0.so.0.1400.1)
==12263==    by 0x534011B: g_main_context_dispatch (in
/usr/lib/libglib-2.0.so.0.1400.1)
==12263==    by 0x534355E: (within /usr/lib/libglib-2.0.so.0.1400.1)
==12263==    by 0x5343908: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1400.1)
==12263==    by 0x4D149E3: gtk_main (gtkmain.c:1144)
==12263==    by 0x495D260: Gtk::Main::run_impl() (main.cc:534)
==12263==    by 0x495D06D: Gtk::Main::run() (main.cc:481)
==12263==    by 0x8351A61: main (main.cpp:103)

Thread 2: status = VgTs_Runnable
==12263==    at 0x4023326: operator new(unsigned) (vg_replace_malloc.c:224)
==12263==    by 0x845F271:
__gnu_cxx::new_allocator<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int>
>::allocate(unsigned, void const*) (new_allocator.h:91)
==12263==    by 0x845F295:
std::_Vector_base<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int>,
std::allocator<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int> >
>::_M_allocate(unsigned) (stl_vector.h:128)
==12263==    by 0x8461098: std::vector<std::pair<Glib::RefPtr<Gdk::Pixbuf>,
int>, std::allocator<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int> >
>::_M_fill_insert(__gnu_cxx::__normal_iterator<std::pair<Glib::RefPtr<Gdk::Pixbuf>,
int>*, std::vector<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int>,
std::allocator<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int> > > >, unsigned,
std::pair<Glib::RefPtr<Gdk::Pixbuf>, int> const&) (vector.tcc:354)
==12263==    by 0x8461361: std::vector<std::pair<Glib::RefPtr<Gdk::Pixbuf>,
int>, std::allocator<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int> >
>::insert(__gnu_cxx::__normal_iterator<std::pair<Glib::RefPtr<Gdk::Pixbuf>,
int>*, std::vector<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int>,
std::allocator<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int> > > >, unsigned,
std::pair<Glib::RefPtr<Gdk::Pixbuf>, int> const&) (stl_vector.h:653)
==12263==    by 0x84613E4: std::vector<std::pair<Glib::RefPtr<Gdk::Pixbuf>,
int>, std::allocator<std::pair<Glib::RefPtr<Gdk::Pixbuf>, int> >
>::resize(unsigned, std::pair<Glib::RefPtr<Gdk::Pixbuf>, int>) (stl_vector.h:421)
==12263==    by 0x8461560:
studio::WorkAreaTarget::start_frame(synfig::ProgressCallback*) (workarea.cpp:285)
==12263==    by 0x838075E:
AsyncTarget_Tile::start_frame(synfig::ProgressCallback*) (asyncrenderer.cpp:162)
==12263==    by 0x4332310:
synfig::Target_Tile::render(synfig::ProgressCallback*) (target_tile.cpp:350)
==12263==    by 0x837D67E: studio::AsyncRenderer::render_target()
(asyncrenderer.cpp:535)
==12263==    by 0x837FBDE: sigc::bound_mem_functor0<void,
studio::AsyncRenderer>::operator()() const (mem_fun.h:1787)
==12263==    by 0x837FBF5: sigc::adaptor_functor<sigc::bound_mem_functor0<void,
studio::AsyncRenderer> >::operator()() const (adaptor_trait.h:251)
==12263==    by 0x837FC5B:
sigc::internal::slot_call0<sigc::bound_mem_functor0<void,
studio::AsyncRenderer>, void>::call_it(sigc::internal::slot_rep*) (slot.h:103)
==12263==    by 0x4FC05F7: call_thread_entry_slot (slot.h:440)
==12263==    by 0x53635AE: (within /usr/lib/libglib-2.0.so.0.1400.1)
==12263==    by 0x4025A6F: mythread_wrapper (hg_intercepts.c:193)
==12263==    by 0x472546A: start_thread (in /lib/tls/i686/cmov/libpthread-2.6.1.so)
==12263==    by 0x55C56DD: clone (in /lib/tls/i686/cmov/libc-2.6.1.so)


Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using.  Thanks.
Comment 1 Julian Seward 2008-02-28 23:43:29 UTC
> Helgrind: Fatal internal error -- cannot continue.
> Helgrind: mk_SHVAL_ShR(tset=19,lset=356247): FAILED


Urr, that's something we will have to fix properly for the 3.4
series.  Unfortunately fixing it properly soaks up even more
memory and CPU resources.

In the meantime try the following kludge.  Find 

  #define N_LSID_BITS  17

at hg_main.c:899 or thereabouts.  Change it to 18, rebuild,
try again.  It may still die; try 18, 19, 20, etc.  Let me know
if it works/does not work.

Looks like you application allocated and deallocates a very
large number of locks.  Yes?  If so you might be able to
avoid the problem by reusing locks rather than deallocating
the memory they occupy, and then reallocate them.
Comment 2 Chris Moore 2008-02-29 01:01:39 UTC
It does allocate a large number of locks, but doesn't use most of them I think.  It took 3 or 4 hours to get to the point of crashing, so it's going to take a while to find the optimum number of bits.

The problem I'm trying to debug doesn't show up on Linux at all - only on Windows, but I've been unable to find any memory debugging tool like valgrind that will work with gcc-linked applications on Windows.  Even the commercial 'purify' app doesn't support gcc (mingw) so I'm hoping I can find the problem using valgrind/helgrind on Linux.
Comment 3 Nicholas Nethercote 2009-06-26 07:00:50 UTC
Julian, what's the status of this one?
Comment 4 Nicholas Nethercote 2009-06-29 08:56:37 UTC
The FAQ.txt message has been fixed, so I'm renaming this bug to reflect the crash.