Opened 6 years ago

#203 new defect - wrong answer

lgActive problem

Reported by: Gary J. Ferland Owned by: Gary J. Ferland
Priority: critical Milestone: C13 branch
Component: atomic/molecular data base Version: trunk
Keywords: Cc:

Description

Robin's summary

There should be no valgrind failure either on the trunk or c10_branch. The issue now is whether what the code actually *does* is correct.

It's not that complex --

$ grep lgActive *.cpp *.h

generates 17 hits on the trunk and 12 on c10_branch. Of these, in either case only 4 are sets.

On the trunk, lgActive is set to true at species.cpp:390, on an iteration over all members of the array which is created at species.cpp:360, so it's clear it cannot be uninitialized.

On c10_branch, I added lgActive = false to SpeciesJunk?, as this seemed to be the safest thing to do to quiet valgrind, without having to figure out the logic of the code or worry about breaking the release branch -- basically this just implements what SpeciesJunk? ought to do anyhow.

However, the fact that valgrind reported this as use of an uninitialized variable in the first place (and that it is different on the trunk), suggests that the logic of how it set is incorrect. The meat of this is at species2.cpp from line 125 on the trunk. The valgrind failures suggest that either lgActive needs to be set earlier in an iteration -- as the variable being accessed before you get here -- or that the conv.nTotalIoniz==0 isn't sufficient to ensure that lgActive is set true the first time through. The logic here seems pretty convoluted to me.

Change History (0)

Note: See TracTickets for help on using tickets.