|
From: SFBay A. <sfb...@gm...> - 2012-03-02 09:13:19
|
Hi, I have started coding in C++ and use a lot of templates, and I do mean a lot. Unfortunately, my type names became way too long for Valgrind to handle. Currently, it seems that it cuts the type name at around 4100 characters (slightly less than that). That is not much of a problem per se, but it means I do not know where the error is reported to be (the file+line number combination is missing). Any idea where the error message length is specified? I am using memcheck and the newest stable Valgrind 3.7.0. Here comes an example of this behavior: ==25348== by 0x4054E4: mfmc::project::project_t<mfmc::model::model_spin_multipoint_t<mfmc::distribution::ising_t<2u, double, int, cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> > >, mfmc::basis::basis_polynomial_t<int, double, cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, 0u, 1u>, mfmc::dag::coarsening::stopping_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> > >, mfmc::dag::coarsening::reconnecting_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, cxxg::metric::compute_neighborhood_t<cxxg::metric::periodic_euclidean_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int>, double>, cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, cxxg::neighborhood::neighborhood_bfs_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, true>, true> >, cxxg::algorithm::mis_frontier_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, true>, mfmc::dag::dag_natural_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, mfmc::dag::coarsening::stopping_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> > >, mfmc::dag::coarsening::reconnecting_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, cxxg::metric::compute_neighborhood_t<cxxg::metric::periodic_euclidean_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int>, double>, cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, cxxg::neighborhood::neighborhood_bfs_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, true>, true> >, cxxg::algorithm::mis_frontier_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, true> > >, 1u>::compute(mfmc::model::model_spin_multipoint_t<mfmc::distribution::ising_t<2u, double, int, cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> > >, mfmc::basis::basis_polynomial_t<int, double, cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, 0u, 1u>, mfmc::dag::coarsening::stopping_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> > >, mfmc::dag::coarsening::reconnecting_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, cxxg::metric::compute_neighborhood_t<cxxg::metric::periodic_euclidean_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int>, double>, cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, cxxg::neighborhood::neighborhood_bfs_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, true>, true> >, cxxg::algorithm::mis_frontier_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, true>, mfmc::dag::dag_natural_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, mfmc::dag::coarsening::stopping_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> > >, mfmc::dag::coarsening::reconnecting_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, cxxg::metric::compute_neighborhood_t<cxxg::metric::periodic_euclidean_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int>, double>, cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, cxxg::neighborhood::neighborhood_bfs_t<cxxg::graph_t<cxxg::node_equivalent_position_t<cxxg::edge_t, unsigned int, 2u, unsigned int> >, true>, true> >, cxxg::algorithm::mis_frontier_t<cxxg::gr Help will be greatly appreciated! Thanks, Jakub |
|
From: Julian S. <js...@ac...> - 2012-03-02 11:41:57
|
On Friday, March 02, 2012, SFBay Area wrote: > Hi, > > I have started coding in C++ and use a lot of templates, and I do mean a > lot. Unfortunately, my type names became way too long for Valgrind to > handle. Currently, it seems that it cuts the type name at around 4100 > characters (slightly less than that). That is not much of a problem per se, > but it means I do not know where the error is reported to be (the file+line > number combination is missing). Any idea where the error message length is > specified? I am using memcheck and the newest stable Valgrind 3.7.0. It might be BUF_LEN defined in VG_(describe_IP) in coregrind/m_debuginfo/debuginfo.c, currently 4096. Alternatively you can use --demangle=no and demangle the output by hand by pushing it through c++filt. J |
|
From: Florian K. <br...@ac...> - 2012-03-03 15:42:12
|
On 03/02/2012 06:39 AM, Julian Seward wrote:
> On Friday, March 02, 2012, SFBay Area wrote:
>> Hi,
>>
>> I have started coding in C++ and use a lot of templates, and I do mean a
>> lot. Unfortunately, my type names became way too long for Valgrind to
>> handle. Currently, it seems that it cuts the type name at around 4100
>> characters (slightly less than that). That is not much of a problem per se,
>> but it means I do not know where the error is reported to be (the file+line
>> number combination is missing). Any idea where the error message length is
>> specified? I am using memcheck and the newest stable Valgrind 3.7.0.
>
> It might be BUF_LEN defined in VG_(describe_IP) in
> coregrind/m_debuginfo/debuginfo.c, currently 4096.
> Alternatively you can use --demangle=no and demangle
> the output by hand by pushing it through c++filt.
>
There is also a hard-coded limit here:
void VG_(demangle) ( Bool do_cxx_demangling, Bool do_z_demangling,
Char* orig, Char* result, Int result_size )
{
# define N_ZBUF 4096
HChar* demangled = NULL;
HChar z_demangled[N_ZBUF];
If you increase N_ZBUF does it fix your problem?
Florian
|
|
From: SFBay A. <sfb...@gm...> - 2012-03-03 22:49:10
|
> > It might be BUF_LEN defined in VG_(describe_IP) in
> > coregrind/m_debuginfo/debuginfo.c, currently 4096.
> > Alternatively you can use --demangle=no and demangle
> > the output by hand by pushing it through c++filt.
> >
>
> There is also a hard-coded limit here:
>
> void VG_(demangle) ( Bool do_cxx_demangling, Bool do_z_demangling,
> Char* orig, Char* result, Int result_size )
> {
> # define N_ZBUF 4096
> HChar* demangled = NULL;
> HChar z_demangled[N_ZBUF];
>
> If you increase N_ZBUF does it fix your problem?
I will try this in a second. Fixing BUF_LEN and also ERRTXT_LEN in
another file didn't do anything. I stuck with --demangle=no for a
while, but will try to modify this as well.
Thanks,
Jakub
|
|
From: SFBay A. <sfb...@gm...> - 2012-03-04 05:29:24
|
Regarding that demangled name exceeding line length, I found all files in coregrid/ that defined a buffer with length 4096 and changed them all to 32768, now Valgrind works fine. I guess the buffers you guys suggested went through a smaller buffer at some point, getting cut short. Would it be a terrible idea to increase the buffer length in the trunk? Thanks, Jakub |