libpqxx: Make check segmentation fault test 93

Hi Jeroen,

I am having a segmentation fault when running tests on latest commit. I am running Linux (Debian testing), connecting to a local PostgreSQL 11 and not making a shared library.

Steps to reproduce:

cd /tmp
git clone https://github.com/jtv/libpqxx.git
cd libpqxx/
./configure --prefix=/tmp/libpqxx/build --disable-documentation --enable-shared=no
make
make check

output trace (test 93 fails):

[...]
Running: test_090

Running: test_092

Running: test_093
/bin/bash : ligne 5 : 28421 Erreur de segmentation  ${dir}$tst
FAIL: runner
====================================
1 of 1 test failed
Please report to Jeroen T. Vermeulen
====================================
make[3]: *** [Makefile:762: check-TESTS] Error 1
make[3] : on quitte le répertoire « /tmp/libpqxx/test »
make[2]: *** [Makefile:911: check-am] Error 2
make[2] : on quitte le répertoire « /tmp/libpqxx/test »
make[1]: *** [Makefile:669: check-recursive] Error 1
make[1] : on quitte le répertoire « /tmp/libpqxx/test »
make: *** [Makefile:640: check-recursive] Error 1

Don’t hesitate if you need more info!

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 16 (9 by maintainers)

Most upvoted comments

Okay, problem solved… so long as you don’t access result objects from a connection where you installed an error handler after that connection object has been destroyed.

Expect a new release soon.

What does all this mean to you as a user? Probably not too much, because this is a fairly rare situation. Until I’ve solved this I would avoid one particular situation: if you create a connection and provide it with a customer error handler, don’t destroy the connection object until you have destroyed all result objects which were created from that connection.

Thanks! That’s a lot of helpful information. Interestingly, it looks to me as if it’s the logging of the error that’s failing. I wouldn’t have guessed that without the traceback. I’ll have to look into it.

The libpq sounds fine. It really shouldn’t matter much which libpq version you use, as long as it’s not older than the libpq headers against which you compiled libpqxx — and even then nowadays I think it’s probably OK.