I agree, that’s extremely weird. Are you sure LD_LIBRARY_PATH and the build of your binary are consistent, i.e. do you really pick up the ".so"s that correspond to the headers? Running with valgrind should give you some more info on what’s causing the memory corruption.
I have a Ubuntu 9.10 setup and using your test program, I cannot reproduce neither the malloc error report nor the valgrind result. Can you write in one post the test program, compile step and valgrind command showing the errors. Also did you change and system.rootrc settinfs?
Hmmm… so I have a unique setup issue probably. This is a vanilla install so far as I can tell. I’ve never touched the contents of the root configuration files.
One question. How does root-config --cflags --libs figure things out? I had a previous installation of 5.18. When installing the new verions, I simply moved the ~/root directory with 5.22 to ~/oldRoot, and put the 5.26 installation at ~root. I figured, with a new shell, that this would work fine and compilations would point to the correct place. However, I don’t know quite how root-config works, so I suppose I could have something confused.
[quote] I still get this problem in a more complicated program (exact same error message). However, I’m having trouble reproducing it in a simple short test case this time. [/quote]Since the result is quite bizarre (all your environment seems correct and unless there was a problem with the make or the install all should be fine; by the way how did you configure root?), I am guessing that there is an important (build?) variable that change between your simple and your complex program (for example did you verify that all .o files and library have been regenerated after you switched root versions?). So the best way is still most likely to try to find a way to reproduce the problem with a small example so that we can also attempt to reproduce it.
That has fixed the my crash occurring when I tried to use an ifstream object with an instantiated WebPageMaker class. Obviously my class is the problem, however the problem didn’t occur in root 5.22, which is why I ask the expertise here.
Now I have a new problem. This one is very odd, and simple, in that initializing a TCanvas causes a crash. The following program doesn’t work:
I should repeat that if I switch back to 5.22, all of these problems go away:
I also should mention that the benchmark.C macro with root works, as does CINT work. It seems these problems only occur with compiled programs.
In my larger program, when I try to instantiate a TCanvas, for some reason I get more backtrace info. I assume its the same issue as the short program, so I’ll include it here in case people find it illuminating:
This is suspicious. Why do you include some root header file prefixed with ‘root/’ and some without? Are you sure you are always using a consistent set of header file. I bet that the problem is that you have 2 install of ROOT one where the headers are in something/root/ and one where the header are in somewhere_else/include and that both ‘something’ and ‘somewhere_else/include’ and in the include path (i.e -I…) [of course you might actually be using a variant of the issue].
Such a discrepancy could explain both the original malloc error and the fact that it goes away if you re-arrange the header as it would mean that different compilation unit think that the same classes have different layout and/or size … resulting in random crappy behavior of course !.
PS. For example maybe you have ROOT header files in /usr/include/root