Overview
Features
Download
Documentation
Community
Add-Ons & Services

POCO 1.5.2 Data TypeHandler crashes

Please post support and help requests here.

POCO 1.5.2 Data TypeHandler crashes

Postby muellerto » 28 Nov 2013, 11:53

I use a self defined TypeHandler for years to fill up a vector based on a database selection. This doesn't work anymore.

The TypeHandler is defined as follows:
Code: Select all
template <class T> struct Tuple
{
   Poco::DateTime t;
   T value;
};

typedef Tuple<double> NumericTuple;

namespace Poco {
namespace Data {

template <> class TypeHandler<NumericTuple>
{
   public:
   static std::size_t size()
   {
      return 2;
   }
   static void bind(std::size_t pos, const NumericTuple& tuple, AbstractBinder* pBinder, AbstractBinder::Direction dir)
   {
      TypeHandler<DateTime>::bind(pos++, tuple.t, pBinder, dir);
      TypeHandler<double>::bind(pos++, tuple.value, pBinder, dir);
   }
   static void extract(std::size_t pos, NumericTuple& tuple, const NumericTuple& dflt, AbstractExtractor* pExtr)
   {
      TypeHandler<DateTime>::extract(pos++, tuple.t, dflt.t, pExtr);
      TypeHandler<double>::extract(pos++, tuple.value, dflt.value, pExtr); // <------ crash!
   }
   static void prepare(std::size_t pos, const NumericTuple& tuple, AbstractPreparator* pPrep)
   {
      TypeHandler<DateTime>::prepare(pos++, tuple.t, pPrep);
      TypeHandler<double>::prepare(pos++, tuple.value, pPrep);
   }
};
}} // namespaces

The database selection is done as follows:
Code: Select all
vector<NumericTuple> tuples;
Statement stmt(*m_pSession);
stmt << "SELECT t, value FROM TNumericData WHERE collection = 34 ORDER BY 1;", K::into(tuples);
stmt.execute();

This should fill up the vector with NumericTuples using the static extract function of the TypeHandler for NumericTuples. This function is called but it crashes with a SEGFAULT in the second extract as marked above. This happens on MySQL and SQLite on my 64bit Linux.
muellerto
 
Posts: 23
Joined: 13 May 2009, 18:06

Re: POCO 1.5.2 Data TypeHandler crashes

Postby muellerto » 28 Nov 2013, 18:28

Ah, now I see in the samples the AbstractExtractor* has been changed into AbstractExtractor::Ptr.

Great.

My compiler says nothing, not a single warning about this, he just compiles crap and I don't know how many such things I have now in my code. This is possible because of implicit type cast operators implemented in your Ptr class. A Ptr is not a pointer and it should not have implicit conversion operators to a plain pointer for lazy people. If you need a Ptr instance you must force the programmer to give you one.

The same problem I noticed already in the JSON parser related to it's handler. Damned.
muellerto
 
Posts: 23
Joined: 13 May 2009, 18:06


Return to Support

Who is online

Users browsing this forum: No registered users and 2 guests