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.
> 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.
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.
Julian, what's the status of this one?
The FAQ.txt message has been fixed, so I'm renaming this bug to reflect the crash.