64-bit crash for nightly tests for 2008 and earlier

[genevb]

I tried DEV, SL23f, and SL21d 64bit, all of which crash seg fault after the following line is printed in the logs:

StChain:INFO  - St_geant_Maker::InitRun -- Do mag.field initialization

In 32-bit, which doesn't crash, the following line is printed next:

 looping on agvolume

Unfortunately, it does not appear that we have functioning gdb for 64-bit, so I cannot easily find the line where the code is crashing (perhaps gdb should be a separate issue?):

gdb: symbol lookup error: gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject

How to reproduce:

setup 64b
stardev
root4star -b -q -l 'bfc.C(1,"pp2003,VFPPV,v0,xi,l3onl,beamLine,logger,CMuDst,-svtIT,NossdIT,Corr2","/star/rcf/test/daq/2003/095/st_physics_4095050_raw_0010002.daq")'

(it doesn't matter whether you run optimized or not, container or not)

-Gene

[genevb]

Here is a list of 64-bit nightly test logs that demonstrate the failure in 64-bit
-rw-r--r-- 1 starreco rhstar 155558 Mar 29 12:15 daq_sl302.ittf_opt/Sat/year_2003/ppMinBias_64bit/st_physics_4095050_raw_0010002.log -rw-r--r-- 1 starreco rhstar 169796 Mar 29 12:16 daq_sl302.ittf_opt/Sat/year_2004/AuAuMinBias_64bit/st_physics_5028066_raw_1010003.log -rw-r--r-- 1 starreco rhstar 169945 Mar 29 12:17 daq_sl302.ittf_opt/Sat/year_2004/AuAu_prodHigh_64bit/st_physics_5044102_raw_1010003.log -rw-r--r-- 1 starreco rhstar 169928 Mar 29 12:17 daq_sl302.ittf_opt/Sat/year_2004/AuAu_prodLow_64bit/st_physics_5044116_raw_3010002.log -rw-r--r-- 1 starreco rhstar 167412 Mar 29 12:16 daq_sl302.ittf_opt/Sat/year_2004/prodPP_64bit/st_physics_5134013_raw_2010010.log -rw-r--r-- 1 starreco rhstar 153538 Mar 29 12:16 daq_sl302.ittf_opt/Sat/year_2008/ppProduction2008_64bit/st_physics_9043046_raw_2030002.log -rw-r--r-- 1 starreco rhstar 152508 Mar 29 12:15 daq_sl302.ittf_opt/Sat/year_2008/production_dAu2008_64bit/st_physics_8352025_raw_1030011.log -rw-r--r-- 1 starreco rhstar 169796 Mar 29 12:17 daq_sl302.ittf/Sat/year_2004/AuAuMinBias_64bit/st_physics_5028066_raw_1010003.log -rw-r--r-- 1 starreco rhstar 152507 Mar 29 12:16 daq_sl302.ittf/Sat/year_2008/production_dAu2008_64bit/st_physics_8352025_raw_1030011.log

[genevb]

Sorry....trying that list again to try to be more clear...

/star/rcf/test/dev/daq_sl302.ittf_opt/Sat/year_2003/ppMinBias_64bit/st_physics_4095050_raw_0010002.log
/star/rcf/test/dev/daq_sl302.ittf_opt/Sat/year_2004/AuAuMinBias_64bit/st_physics_5028066_raw_1010003.log
/star/rcf/test/dev/daq_sl302.ittf_opt/Sat/year_2004/AuAu_prodHigh_64bit/st_physics_5044102_raw_1010003.log
/star/rcf/test/dev/daq_sl302.ittf_opt/Sat/year_2004/AuAu_prodLow_64bit/st_physics_5044116_raw_3010002.log
/star/rcf/test/dev/daq_sl302.ittf_opt/Sat/year_2004/prodPP_64bit/st_physics_5134013_raw_2010010.log
/star/rcf/test/dev/daq_sl302.ittf_opt/Sat/year_2008/ppProduction2008_64bit/st_physics_9043046_raw_2030002.log
/star/rcf/test/dev/daq_sl302.ittf_opt/Sat/year_2008/production_dAu2008_64bit/st_physics_8352025_raw_1030011.log
/star/rcf/test/dev/daq_sl302.ittf/Sat/year_2004/AuAuMinBias_64bit/st_physics_5028066_raw_1010003.log
/star/rcf/test/dev/daq_sl302.ittf/Sat/year_2008/production_dAu2008_64bit/st_physics_8352025_raw_1030011.log

[klendathu2k]

FYI -- gdb works with python3:

$ module unload python-2.7.18
$ gdb
...

[klendathu2k]

This is the issue I noted ~few weeks ago with the TOF geometry. There is an unexpected / untested null pointer returned when iterating over the tray volumes.

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe27d7faa in StTofrGeometry::InitFromStar (this=0xd253280, starHall=0xd288c90) at .sl73_x8664_gcc485/obj/StRoot/StTofUtil/StTofrGeometry.cxx:1290
warning: Source file is more recent than executable.
1290        if ( trayVolume->GetListSize() ) {
(gdb) list
1285      TDataSetIter nextSector(mTopNode);
1286      TVolumeView *secVolume = 0;
1287      mTrays = 0;     // non-emtry tray number
1288      while ( (secVolume = (TVolumeView *)nextSector()) ) {
1289        TVolumeView *trayVolume = (TVolumeView *)secVolume->First();
1290        if ( trayVolume->GetListSize() ) {
1291          mTrays++;
1292          mModulesInTray = trayVolume->GetListSize();
1293        }
1294      }
(gdb) 

[genevb]

Thanks for the quick find, @klendathu2k . I've added some TOF folks to the assignees.

[klendathu2k]

.... earliest 64b library I could find to test was SL19b. It still shows the issue.

[klendathu2k]

Quick sanity check. The y2003 geometry appears to be the same in 32b and 64b. At least the same # of volumes.

Next, ran the StRoot/macros/starsim.C. Modified so that it creates the TVolume (not to be confused with TGeoVolume) geometry. This is the geometry model used as input to the TofGeometry utility. I see identical number of volumes between 32b and 64b. So I believe the inputs are the same between 32b and 64b.

I confirm that 32b and 64b are both calling the same initialization method.... InitFromStar. 32bit runs fine, but 64b dies inside.

[darkmatterist]

Hi all, May I ask what’s the problem here and do the TOF folks need to do anything? Thank you. Sincerely, Chenliang

…

On Mar 29, 2025, at 7:06 PM, klendathu2k ***@***.***> wrote: klendathu2k left a comment (star-bnl/star-sw#742) Quick sanity check. The y2003 geometry appears to be the same in 32b and 64b. At least the same # of volumes. Next, ran the StRoot/macros/starsim.C. Modified so that it creates the TVolume (not to be confused with TGeoVolume) geometry. This is the geometry model used as input to the TofGeometry utility. I see identical number of volumes between 32b and 64b. So I believe the inputs are the same between 32b and 64b. I confirm that 32b and 64b are both calling the same initialization method.... InitFromStar. 32bit runs fine, but 64b dies inside. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned. <#742 (comment)> <https://github.com/notifications/unsubscribe-auth/AOQVCLWDAT665OEJQKERRUD2W4YPRAVCNFSM6AAAAAB2BU57MCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRUGI4TQOBSGY> klendathu2k left a comment (star-bnl/star-sw#742) <#742 (comment)> Quick sanity check. The y2003 geometry appears to be the same in 32b and 64b. At least the same # of volumes. Next, ran the StRoot/macros/starsim.C. Modified so that it creates the TVolume (not to be confused with TGeoVolume) geometry. This is the geometry model used as input to the TofGeometry utility. I see identical number of volumes between 32b and 64b. So I believe the inputs are the same between 32b and 64b. I confirm that 32b and 64b are both calling the same initialization method.... InitFromStar. 32bit runs fine, but 64b dies inside. — Reply to this email directly, view it on GitHub <#742 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQVCLWDAT665OEJQKERRUD2W4YPRAVCNFSM6AAAAAB2BU57MCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRUGI4TQOBSGY>. You are receiving this because you were assigned.

[klendathu2k]

The problem is that the code crashes when compiled under 64 bits. Gene showed how to reproduce...

setup 64b
stardev
root4star -b -q -l 'bfc.C(1,"pp2003,VFPPV,v0,xi,l3onl,beamLine,logger,CMuDst,-svtIT,NossdIT,Corr2","/star/rcf/test/daq/2003/095/st_physics_4095050_raw_0010002.daq")'

Not clear what the best way to help debug would be at this point.

Hi all,

May I ask what’s the problem here and do the TOF folks need to do anything? Thank you.

Sincerely,
Chenliang
…

[darkmatterist]

OK, thanks.

…

On Mar 29, 2025, at 7:18 PM, klendathu2k ***@***.***> wrote: klendathu2k left a comment (star-bnl/star-sw#742) The problem is that the code crashes when compiled under 64 bits. Gene showed how to reproduce... setup 64b stardev root4star -b -q -l 'bfc.C(1,"pp2003,VFPPV,v0,xi,l3onl,beamLine,logger,CMuDst,-svtIT,NossdIT,Corr2","/star/rcf/test/daq/2003/095/st_physics_4095050_raw_0010002.daq")' Not clear what the best way to help debug would be at this point. Hi all, May I ask what’s the problem here and do the TOF folks need to do anything? Thank you. Sincerely, Chenliang … — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned. <x-msg://3/#> <#742 (comment)> <https://github.com/notifications/unsubscribe-auth/AOQVCLVV75O4P3TMV6PX7KL2W4Z7DAVCNFSM6AAAAAB2BU57MCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRUGMYDIOBTGM> klendathu2k left a comment (star-bnl/star-sw#742) <#742 (comment)> The problem is that the code crashes when compiled under 64 bits. Gene showed how to reproduce... setup 64b stardev root4star -b -q -l 'bfc.C(1,"pp2003,VFPPV,v0,xi,l3onl,beamLine,logger,CMuDst,-svtIT,NossdIT,Corr2","/star/rcf/test/daq/2003/095/st_physics_4095050_raw_0010002.daq")' Not clear what the best way to help debug would be at this point. Hi all, May I ask what’s the problem here and do the TOF folks need to do anything? Thank you. Sincerely, Chenliang … <x-msg://3/#> — Reply to this email directly, view it on GitHub <#742 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQVCLVV75O4P3TMV6PX7KL2W4Z7DAVCNFSM6AAAAAB2BU57MCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRUGMYDIOBTGM>. You are receiving this because you were assigned.