Author Topic: [MAYBE SOLVED] Lazarus+PostgreSQL - Segmentation faults and stack overflows  (Read 1411 times)


  • New Member
  • *
  • Posts: 38
Hi all,

I quickly tried to connect to a PostgreSQL server via a TPQConnection: put the relevant controls in a form, filled in data (IP addresses, passwords...), solved problems with DLLs in winslow 64 bits, and finally I succeeded in performing SQL queries interactively in TSQLquery dialog box. I even put a DBGrid on the form, and it works - in design mode.

BUT, when the program is run, as soon as the DBGrid is clicked, or a DBNavigator is used, the program crashes. Typical errors are stack overflow and segment fault. The debugger seems lost and does not give reliable informations.

I tried different versions of various DLLs (libpq and companions), but nothing changed.

Then I upgraded Lazarus from 1.6.4 to 1.8.4: nothing changed.
Then I installed Lazarus on a Ubuntu X64 machine, which has a fully functional Postgre server running (in production): nothing changed.

Then, on the same form, I duplicated the same controls as before, side by side, but with a connection to an MS-SQL server. At design time, all is ok. When running, the form starts ok (for both Postgre and MSSQL); the MS-SQL part is fully workable and clickable; as soon as I touch the Postgre part, the program crashes as before. So it seems that the problem lies in TPQConnection, but then why in design mode all is ok?

I've seen that this problem with Postgre has already been reported in this forum, twice this year, with no replies.

What should I do? Does somebody has a suggestion? Should I signal a bug? TY.
« Last Edit: December 11, 2018, 06:16:46 pm by linuxfan »


  • New Member
  • *
  • Posts: 38
Re: Lazarus+PostgreSQL - Segmentation faults and stack overflows
« Reply #1 on: December 11, 2018, 06:15:56 pm »

It turned out that I double linked (forth and back) the SQLQuery with the Datasource (the one referring to the same SQLQuery).
This could explain the stack overflow.

But then, I don't understand what TSQLQuery.Datasource is for. Many years are passed since I last used databases...

Or may be my double link was legitimate?

Just after having write this post, I tried to double link the MSSQL controls on the form, just as I did for Postgre. AH-HA: a nice message box rises up and says: "Circular datasource references are not allowed".

Ok, so something starts to be more clear, even if not completely. If someone feels like give some explanation, I'll be grateful.

« Last Edit: December 11, 2018, 06:22:04 pm by linuxfan »


  • Hero Member
  • *****
  • Posts: 3672
TSQLQuery's Datasource property can be used to construct a master-detail relationship between two datasets.

Setting the Datasource property starts an attempt to fill the parameters with values from the Datasource’s dataset fields.

If a user then scrolls through the master dataset, the detail dataset is closed and then reopened with the new field values.


  • Hero Member
  • *****
  • Posts: 3763
Or as the documentation for TSQLQuery explains:
Datasource can be set to a dataset which will be used to retrieve values for the parameters if they were not explicitly specified.
When Open or ExecSQL is called, and the Datasource property is not Nil then for each parameter for which no value was explicitly set (its Bound property is False), the value will be retrieved from the dataset connected to the datasource.
For each parameter, a field with the same name will be searched, and its value and type will be copied to the (unbound) parameter. The parameter remains unbound.

If a SQLQuery and a Datasource were bound to each other, then on each Open or ExecSQL the Query would consult the Datasource, which would try to get the answers from the SQLQuery which would Open or ExecSQL to get them which would call Datasource, ...

So you see why it's not allowed at design-time ... and a really bad idea to try it at run time :D
« Last Edit: December 11, 2018, 07:18:03 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.


  • New Member
  • *
  • Posts: 38
> So you see why it's not allowed at design-time ... and a really bad idea to try it at run time

In fact, I did it at design time somehow (it should not be allowed); in my test there was not even a single line of code.

Then may be that TPQConnection does not detect circular references, as TSQLConnector does.

Anyway, thanks all for the clarification.


TinyPortal © 2005-2018