sherpa is hosted by Hepforge, IPPP Durham
close Warning: Can't synchronize with repository "(default)" (/hepforge/svn/sherpa does not appear to be a Subversion repository.). Look in the Trac log for more information.
Modify

Opened 16 years ago

Closed 16 years ago

Last modified 10 years ago

#7 closed defect (fixed)

Undefined behavior in LHAPDF on amd64 machines

Reported by: Aleksey.Khudyakov@cern.ch Owned by: support@sherpa-mc.de
Priority: minor Milestone:
Component: Unknown Version: 1.0.11
Keywords: Cc:

Description

When lhapdf is initialized it's can either initialize normally but in some cases it can raise error because of random values in some variables or even segfault.

Error seems to occur only in InitPDFSetM lhapdf routine and more precisely on read statement on line 93 of LHpdflib.f (version 5.3.0). According to valgrind program tries to read some unitialized memory and because of that variable s2 (in InitPDFSetM) contains random values in some cases. Sometimes this may lead to segfault as well.

Bug observed only in specific environment. Currently I've observed it only on amd64 machines.

  • OS: scientific linux 4
  • Compiler version: gcc version 3.4.6 20060404 (Red Hat 3.4.6-8)
  • LHAPDF should be compiled with -g -O2 (-O1 and -O0 hides bug). I didn't tried to remove -g flag.
  • Bug may or may not manifest itself under debugger/other tools.

Valgrind errors. they are quite numerous this only one of them

 ==23995== Invalid read of size 1
 ==23995==    at 0x3FC58142D0: g_char (in /usr/lib64/libg2c.so.0.0.0)
 ==23995==    by 0x3FC5810A87: f_open (in /usr/lib64/libg2c.so.0.0.0)
 ==23995==    by 0x8B94F28: initpdfsetm_ (LHpdflib.f:92)
 ==23995==    by 0x8B94EDC: initpdfset_ (LHpdflib.f:75)
 ==23995==    by 0x8A784BE: PDF::LHAPDF_Fortran_Interface::LHAPDF_Fortran_Interface(ATOOLS::Flavour, std::string, int, std::string, bool&) (basic_string.h:1456)
 ==23995==    by 0x795E689: PDF::PDF_Handler::GetPDFLib(ATOOLS::Data_Read*, ATOOLS::Flavour&, int)  (Flavour.H:551)
 ==23995==    by 0x4B1F83E: SHERPA::Initialization_Handler::InitializeThePDFs()  (Initialization_Handler.C:370)
 ==23995==    by 0x4B2DCBF: SHERPA::Initialization_Handler::InitializeTheFramework(int) (Initialization_Handler.C:212)
 ==23995==    by 0x4A0BA12: SHERPA::Sherpa::InitializeTheRun(int, char**) (Sherpa.C:112)
 ==23995==    by 0x401CD7: main (Main.C:49)
 ==23995==  Address 0x1B815E97 is not stack'd, malloc'd or (recently) free'd

It's very unlikely that this is lhapdf problem because every other program runs smoothly with this library and valgrind could not find any problems.

Attachments (0)

Change History (5)

comment:1 in reply to:  description Changed 16 years ago by Frank Siegert

Hi Aleksey,

thanks for this bug report.

The problem sounds fairly difficult to reproduce, so I don't know exactly when we will get around to solving (or even finding) it, but if you have any more findings in this matter, please let us know. In particular, please provide feedback whether it is still appearing in newer versions when they are released.

It would also be interesting, whether any other user experienced something similar, because we have so far not heard about this problem.

Cheers, Frank

comment:3 Changed 16 years ago by Frank Siegert

Resolution: fixed
Status: newclosed

A patch for this problem is provided on our download page for version 1.0.11. Sherpa does not use the C++ wrapper distributed with LHAPDF, but a very similar own one, which is fixed by this patch. The official LHAPDF wrapper will be fixed in a similar manner and released by the LHAPDF team.

comment:4 Changed 12 years ago by Frank Siegert

Milestone: rel-old

comment:5 Changed 10 years ago by Stefan Hoeche

Milestone: old

Milestone old deleted

Modify Ticket

Change Properties
Action
as closed The owner will remain support@sherpa-mc.de.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.