search

idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.77k stars 1.05k forks source link

modules unit tests are not getting run on linux #15720

Closed brianmoose closed 3 years ago

brianmoose commented 4 years ago

Bug Description

Originally reported by @WilkAndy on the Civet repo but it isn't a Civet problem so I am moving it over here. None of the modules unit tests are being run, example. To be clear, there is an attempt at being run but they all report 0 tests.

Steps to Reproduce

@WilkAndy reports that it works fine on MacOS so this seems to be a linux issue.

To reproduce on linux, in dbg mode, build any of the module unit test executables and run it, for example modules/geochemistry/unit. It reports 0 tests found. lib/libgeochemistry-unit-dbg.so (where all the tests are) is not even linked to the executable (as verified by ldd) even though it definitely is on the link line. This might be due to nothing actually referencing the symbols in libgeochemistry-unit-dbg.so so the linker just silently drops it. Forcing the linkage by, for example, putting a dummy function in one of the unit test source files and calling it from main(), gets the unit tests running again. This seems to be why moose/unit is working, main() calls registerApp(MooseUnitApp) which is in libmoose-unit-dbg.so. The modules don't have separate unit test apps, so they just call registerApp(<Module>App). The other way to possibly fix this would be to not have a separate shared library for the tests and link main.o along with all the test object files.

Impact

Testing good, especially if the tests already exist!

lindsayad commented 4 years ago

@brianmoose ?! Can I assign this to you? :laughing: Hope you're doing well man!

brianmoose commented 4 years ago

Hey @lindsayad ! Things are going well! I have no plans on working on this, just thought I would put it over here so that it gets some attention. Adding all the boilerplate <Module>UnitApp code should be pretty straight forward if that is the preferred solution. Also, somebody who runs linux and is more in tune with moose development should verify. I might have just gone crazy! :smile:

loganharbour commented 4 years ago

Will get around to this once testing is back. Had a fix for it, just never got around to it.

WilkAndy commented 4 years ago

Cool, sounds good, thank @loganharbour

a

WilkAndy commented 3 years ago

I believe this is now fixed, thanks heaps! If you agree, you can close, @loganharbour

brianmoose commented 3 years ago

Still doesn't look like any module unit tests are getting run (or found). here is the latest "Modules Debug" on the next branch, all the modules have zero unit tests found.

WilkAndy commented 3 years ago

OK, that's a bummer. I was looking in a PR and they were getting run during that process. Eg, have a look at https://civet.inl.gov/job/633127/

brianmoose commented 3 years ago

Looks like your working job is using CentOS, my not working job is using Ubuntu 16. That seems to agree with #16092

lindsayad commented 3 years ago

@brianmoose just let us know when you want your job back :smile:

loganharbour commented 3 years ago

I've been playing around with recipes a lot today moving things to the new build machines.

Recipes just updated and Modules debug looks good now: https://civet.inl.gov/job/633406/

Seems like that build config that @brianmoose is borked for cppunit, but... gonna ignore that as we're shifting everything to CentOS 8 on the new build machines now, and the recipe I just linked is in production on next.

brianmoose commented 3 years ago

Glad you figured it out! I wouldn't have looked at cppunit since the modules seem to be using GoogleTest, not sure how cppunit and GoogleTest interact with each other, but as long as it works!

loganharbour commented 3 years ago

Closing per the recipe https://civet.inl.gov/job/633917/