SegV in 5.18/00 handling long strings with --build=debug

Dear Roottalk,

This thread started privately last Thursday when I emailed Rene saying I thought I have found a bug in the code that was about to be tagged as 5.18/00. Code that work with 5.17/08 SegVed with 5.18/00. I saw the problem building directly from the Repository at two separate SL4 sites. Rene took my standalone macro and ran it perfectly on all supported platforms. Once the release was announced I took ROOT's Linux SL4 binary build and confirmed that it worked too.

I think I now at least understand part of the problem. It is to do with the configuration option:-

   --build=debug

If I take the 5.18/00 source tar and configure with:-

  ./configure linux --build=debug

then build and install in the usual way, then:-

  root bug.C

SegVs. For reference my machine is:-

  Scientific Linux SL release 4.5 (Beryllium)   gcc version 3.4.6 20060404 (Red Hat 3.4.6-8)

The bug.C attached contains the statement:-

   jc.Path.Create("Spill",

"DataQualityReader::Reco "
"RecordSetupModule::Get "
"NeardetBeamSelect::Ana "
"DigitListModule::Get "
"DigitListModule::Reco "
"FilterDigitListModule::Reco "
"StripSRListModule::Reco "
"SliceSRListModule::Reco "
"TrackCamListModule::Reco "
"FitTrackCamListModule::Reco "
"ClusterSRListModule::Reco "
"SubShowerSRListModule::Reco "
"ShowerSRListModule::Reco "
"EventSRListModule::Reco "
"RecordSetupModule::Reco "
"NtpBDLite::Reco "

                 );

and the SegV can be fixed by reducing the size of the second string argument. CINT problems handling long strings has been discussed on this list a number of times before, what makes this different is that if the current code is configured without --build=debug, say

  ./configure linux

the problem goes away. It also goes away in 5.17/08 even with --build=debug
so something has changed since then that is sensitive to this option.

There is a simple workaround but if people experience SegVs when moving forward to 5.18/00 and are using the debug option, it's something to bear in mind.

Cheers,

Nick.