Your message dated Sat, 01 Dec 2007 13:41:10 +0200
with message-id <[EMAIL PROTECTED]>
and subject line libcommoncpp2-1.5-0: onTimer() not called upon timer
expiration in PosixThread
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: libcommoncpp2-1.5-0
Version: 1.5.1-4
Severity: important
When using timers in a class derived from PosixThread, the method
onTimer() is not called when the timer expires, although the timer is
running. I wrote a minimal test software to reproduce this problem.
The problem does not arise on other systems (e.g. RHEL 4) with the
same commoncpp version. As far as i found out, it must have something to
do with the kernel version/c library or a combination of those.
on a system running kernel 2.6.9 it works, on a system with 2.6.11
it does no longer work... so far i did not try to run a debian etch system
with a 2.6.9 to verify, maybe you find the problem faster than me ;-)
The minimal setup:
------ start of test source ------
------ Makefile ------
LIB_INCLUDES=-lccext2 -lccgnu2 -lz -ldl -lxml2
CFLAGS=-Wall -fexceptions
all: pleaseCall
./CiTimer.o: ./CiTimer.cpp ./CiTimer.hpp
$(CXX) $(CFLAGS) $(INCLUDES) -c -g -o $@ ./CiTimer.cpp
pleaseCall: ./pleaseCall.cpp \
./CiTimer.o
$(CXX) $(CFLAGS) $(INCLUDES) $(LIB_INCLUDES) -g -o $@ ./pleaseCall.cpp
./CiTimer.o
clean:
rm -f ./CiTimer.o
rm -f ./pleaseCall
------ CiTimer.cpp ------
#include <cc++/thread.h>
#include <iostream>
#include "CiTimer.hpp"
using namespace std;
using namespace ost;
/**
* \brief standard constructor
*/
CiTimer::CiTimer() : PosixThread()
{
start();
}
/**
* \brief standard destructor cleans up dynamical objects and close the
* common interface timer
*/
CiTimer::~CiTimer()
{
}
/**
* \brief function of PosixThread, which is called if the timer expired
*/
void CiTimer::onTimer(void)
{
cout << "!!! onTimer() called !!!" << endl;
}
/**
* \brief run method of PosixThread
*/
void CiTimer::run()
{
cout << "Starting test run ..." << endl;
setTimer(1000, true);
while (1)
{
cout << "getTimer() returns: " << getTimer() << endl;
Thread::sleep(300);
}
}
------ CiTimer.hpp ------
using namespace std;
using namespace ost;
class CiTimer : public PosixThread
{
public:
CiTimer();
~CiTimer();
private:
virtual void onTimer(void);
void run();
};
----- pleaseCall.cpp
nclude "CiTimer.hpp"
using namespace std;
int main(int arg, char *argv[])
{
CiTimer* pCiTimer;
pCiTimer = new CiTimer();
while (1) {
Thread::sleep(1000);
}
return 1;
}
------ end of test source ------
The software starts a timer in the class derived from PosixThread and
continously reads the timer value to prove the timer is running.
If the onTimer() gets called the program makes happy outputs.
This call does not happen on Debian etch, but works on other distributions
with - as is my knowledge so far - kernels < 2.6.10.
thanks for fixing!
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-1)
(ignored: LC_ALL set to en_US)
Versions of packages libcommoncpp2-1.5-0 depends on:
ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-21 GCC support library
ii libgcrypt11 1.2.3-2 LGPL Crypto library - runtime libr
ii libgnutls13 1.4.4-3 the GNU TLS library - runtime libr
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
libcommoncpp2-1.5-0 recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
So, if I get this right, this is considered as a known limitation by
upstream and not a bug.
Therefore, there's no sense on carrying this on our BTS since a) it's an
upstream issue b) it won't get fixed so there's no point in tracking it.
If I didn't get this right, feel free to reopen it.
Thanks,
Faidon
--- End Message ---