#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 Changed 17 years ago by
comment:2 Changed 17 years ago by
comment:3 Changed 17 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 13 years ago by
Milestone: | → rel-old |
---|
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