3 Replies Latest reply on Nov 17, 2008 9:56 AM by Clebert Suconic

    Build is now failing for a different reason

    Tim Fox Master

      After the QA lab outage, the build is failing every time.

      Something to do with the AOI shared lib. Maybe it's using the 32 bit one when it should be using the 64 bit one?

        • 1. Re: Build is now failing for a different reason
          Tim Fox Master

           

           [junit] TEST org.jboss.messaging.tests.integration.asyncio.MultiThreadWriteNativeTest FAILED
           [junit] Running org.jboss.messaging.tests.integration.asyncio.SingleThreadWriteNativeTest
           [junit] #
           [junit] # An unexpected error has been detected by HotSpot Virtual Machine:
           [junit] #
           [junit] # SIGSEGV (0xb) at pc=0x6c206de1, pid=26865, tid=3086354640
           [junit] #
           [junit] # Java VM: Java HotSpot(TM) Server VM (1.5.0_15-b04 mixed mode)
           [junit] # Problematic frame:
           [junit] # C [libJBMLibAIO32.so+0x2de1] _ZN13AIOController7destroyERP7JNIEnv_+0x15
           [junit] #
           [junit] # An error report file with more information is saved as hs_err_pid26865.log
           [junit] #
           [junit] # If you would like to submit a bug report, please visit:
           [junit] # http://java.sun.com/webapps/bugreport/crash.jsp
           [junit] #
           [junit] Running org.jboss.messaging.tests.unit.util.XMLUtilTest
           [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
           [junit] Tests FAILED (crashed)
           [report] processing input files ...
           [report] 1 file(s) read and merged in 66 ms
           [report] nothing to do: no runtime coverage data found in any of the data files
          


          • 2. Re: Build is now failing for a different reason
            Tim Fox Master

            Or maybe the new machines don't have AIO installed

            • 3. Re: Build is now failing for a different reason
              Clebert Suconic Master

              They changed users on Hudson. Because of that the latest build under the older user had left a file created... the new build couldn't open one of the files...

              (You will find an exception on the build as "Can't open file").



              And that has fired a bug on the Native Layer. I'm first opening the files before getting a handle for the Logger on the native layer. As a result later it will try to free a resource that wasn't allocated and that will cause the crash :-).


              For now we need to get QA to delete the file, and I will make sure the test is deleting the file on tear down. (I used to read the files using bvi).


              And I will also fix the bug on the native layer.