qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: FW: problems starting the version 18 broker and its Crash
Date Fri, 07 Sep 2012 14:20:32 GMT
On 09/07/2012 02:43 PM, Nitin Shah wrote:
> Hi,
> Thanks for the information. I started doing some investigation on the
> new release mainly because I could not see what we were ( if
> possible) doing wrong with the release. The broker would start
> executing and immediately one was getting an assert as shown below in
> the output I generated with running it under GDB. It asserts because
> it fails the test in file types.cpp in qpid/ha line 38 ( assert(value
> < count). I noticed that this is happening as a result of the call
> from the HaBroker::initialize() function line 90 in the HaBroker.cpp
> file where a QPID_LOG is being invoked.
> I believe the root of the problem is the BrokerInfo class constructor
> is not initializing the private class data called "BrokerStatus
> status" which is defined in file BrokerInfo.h .

Good analysis; thanks!

> *****I assume we are going to need a patch or an update for the
> broker to be used.
> NOTE:: If I start the broker with the "--log-enable warning" or for
> that matter others like notice, the broker comes up and works fine.
> But, if the broker is started with no log-enable parameters, IT
> CRASHES. This seems pretty strange as I thought you guys would have
> seen this.

It actually works fine for me for repeated restarts, though if I run 
under valgrind the uninitialised value is reported and of course by 
inspection of the code you have correctly identified a problem.

I guess we have just been unlucky in not hitting the problem...

> I am running the broker on a CentOs 6.2 system. We have been using
> version 16 to date. The images are created a new and loaded on a VM,
> so the VM has no remnants of the version 16, so it is  clean version
> 18 load and use.
> If I wish to continue using this release, can someone tell me what
> the correct process for getting a patch is? Alternatively, what is
> the patch I should apply, meaning can I add a initialize of the
> status parameter and what is the CORRECT enum value to set it to?

The attached patch should take care of the crash. I believe the status 
is correctly set later on, just not in time for the logging statement.

View raw message