|
From: Greg C. <gre...@ya...> - 2013-02-19 18:00:01
|
Hello, Valgrind 3.4.0 and 3.8.0 asserts because we have large generated C functions which compile into very large code blocks causing valgrind to valgrind: m_debuginfo/storage.c:456 (vgModuleLocal_addDiCfSI): Assertion 'cfsi.len < 5000000' failed. ==30429== at 0x3802EDA7: report_and_quit (m_libcassert.c:235) ==30429== by 0x3802EFDB: vgPlain_assert_fail (m_libcassert.c:309) ==30429== by 0x38067FA0: vgModuleLocal_addDiCfSI (storage.c:456) ==30429== by 0x380B0E25: run_CF_instructions (readdwarf.c:3622) ==30429== by 0x380B1AE1: vgModuleLocal_read_callframe_info_dwarf3 (readdwarf.c:4173) ==30429== by 0x3805FB77: vgModuleLocal_read_elf_debug_info (readelf.c:2486) ==30429== by 0x3805A999: di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:611) ==30429== by 0x3805B48A: vgPlain_di_notify_mmap (debuginfo.c:918) ==30429== by 0x3808342A: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2066) ==30429== by 0x380A46C2: vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:1012) ==30429== by 0x38077438: vgPlain_client_syscall (syswrap-main.c:1451) ==30429== by 0x38075935: vgPlain_scheduler (scheduler.c:1057) ==30429== by 0x3809C6E6: run_a_thread_NORETURN (syswrap-linux.c:102) How does one increase this number? Is it in any way related to this? ./VEX/priv/main_util.c:#define N_TEMPORARY_BYTES 5000000 Thanks, Greg |
|
From: Dan K. <da...@ke...> - 2013-02-19 18:06:16
|
On Tue, Feb 19, 2013 at 9:53 AM, Greg Czajkowski
<gre...@ya...> wrote:
> valgrind: m_debuginfo/storage.c:456 (vgModuleLocal_addDiCfSI): Assertion
> 'cfsi.len < 5000000' failed.
>
> How does one increase this number?
Check out the valgrind source code,
edit coregrind/m_debuginfo/storage.c,
change the lines
/* If this fails, the implication is you have a single procedure
with more than 5 million bytes of code. Which is pretty
unlikely. Either that, or the debuginfo reader is somehow
broken. 5 million is of course arbitrary; but it's big enough
to be bigger than the size of any plausible piece of code that
would fall within a single procedure. */
vg_assert(cfsi.len < 5000000);
and recompile.
> Is it in any way related to this?
>
> ./VEX/priv/main_util.c:#define N_TEMPORARY_BYTES 5000000
I don't think so?
|
|
From: Florian K. <br...@ac...> - 2013-02-19 18:42:29
|
On 02/19/2013 12:53 PM, Greg Czajkowski wrote: > Hello, > > Valgrind 3.4.0 and 3.8.0 asserts because we have large generated C functions which compile into very large code blocks causing valgrind to > > > valgrind: m_debuginfo/storage.c:456 (vgModuleLocal_addDiCfSI): Assertion 'cfsi.len < 5000000' failed. ...snip... > > > How does one increase this number? You cannot do this via command line. Check out the valgrind source, comment out the assertion above. build valgrind and try running again. >From a quick look at the source the assert is not related to some array limit or such. So you might just get lucky with what I described. > Is it in any way related to this? > > ./VEX/priv/main_util.c:#define N_TEMPORARY_BYTES 5000000 > No, not related. Florian |
|
From: Greg C. <gre...@ya...> - 2013-02-20 15:09:37
|
> From a quick look at the source the assert is not related to some array > limit or such. So you might just get lucky with what I described. If this assertion is not tied to any possible damage it may cause, can it be removed or perhaps turned into a warning? BTW. After removing the assertion, the process runs much further, but eventually (after a day) valgrind hangs somewhere and stops consuming the CPU. First time ever I have seen such behaviour, at the same time our processes have always stretched valgrind. Greg |
|
From: Philippe W. <phi...@sk...> - 2013-02-20 19:06:08
|
On Wed, 2013-02-20 at 07:09 -0800, Greg Czajkowski wrote: > If this assertion is not tied to any possible damage it may cause, can > it be removed or perhaps turned into a warning? A warning is similar to other similar things in Valgrind. E.g. a warning is produced when the permission of a large address range is changed. > > BTW. After removing the assertion, the process runs much further, but > eventually (after a day) valgrind hangs somewhere and stops consuming > the CPU. First time ever I have seen such behaviour, at the same time > our processes have always stretched valgrind. You might use gdb+vgdb to connect to Valgrind and examine what is the state of your process and of the Valgrind scheduler. Philippe |