[SOLVED] This is driving me mad: "Inconsistency detected by ld.so"

[Zvoni]

Hi folks,

close to deleting FPC/Lazarus.

Ubuntu18.10-64bit/FPC304/Laz200

Library with exported functions.
First call to the library creates a Thread, which takes over as MainThread (because of CheckSynchronize).

This FakeMainthread creates a/many childthreads. Everything woking so far.
The moment i add DB-Components to the Childthreads, everything goes south.

If i use MySQL in the TSQLConnector, it works (with one thread! Many threads it still goes haywire)
If i use SQLite3 i get the Error-MEssage
"Inconsistency detected by ld.so: dl-minimal.c: 126: realloc: Assertion `ptr == alloc_last_block' failed!"
I found exactly one thread in the forum having the error-message. And the discussion there didn't help.

cthreads is the first Unit in the libraray.lpr
and i don't use cmem, because that one doesn't work for me (heaptrc always saying no Memory leaks), and i get a lot of corrupted memory from cmem.

Help?

EDIT: I forgot: The error occurs after connection has been established (connection.connected returns true), on the first try to grab any information from the database (Query.Open, Connection.GetTableNames etc.)

EDIT2: Before anyone asks: YEs, i have successfully worked with SQLite under FPC304, so i don't understand what's happening here, since i don't do anything different than before

EDIT3: And yes: Each thread has its own DB-Conn, Trans and Query! I'm not mixing them, and the threads/db-components don't have to talk with each other.

[Thaddy]

and i don't use cmem, because that one doesn't work for me (heaptrc always saying no Memory leaks), and i get a lot of corrupted memory from cmem.

That is because you overlooked  that heaptrc IS a memory manager by itself, so if you hook cmem, heaptrc won't work anymore.
You can safely use heaptrc and if no leaks are detected change it to cmem. That's what heaptrc is designed for.
Just to be sure: you should let the compiler insert heaptrc and not put it in any uses clause.

The above problems can be wholly caused by mixing two different memory managers, so try first heaptrc without cmem and then with just cmem and without the heaptrc option set.
If there is still memory corruption we need to look further.

The reason I suspect this is the case is the following:
When the compiler inserts heaptrc it does so *before* anything else is done and heaptrc already allocates memory by itself to be able to register all memory allocations/de-allocations. (that's why it is done by the compiler! and not through a uses clause)
That memory is lost when you subsequently set a different memory manager: acute memory corruption.

[Zvoni]

and i don't use cmem, because that one doesn't work for me (heaptrc always saying no Memory leaks), and i get a lot of corrupted memory from cmem.

That is because you overlooked  that heaptrc IS a memory manager by itself, so if you hook cmem, heaptrc won't work anymore.
You can safely use heaptrc and if no leaks are detected change it to cmem. That's what heaptrc is designed for.
Just to be sure: you should let the compiler insert heaptrc and not put it in any uses clause.

No heaptrc in Uses-clause. I added it in Project-Options-Debugger (Dwarf2)
And i've removed cmem from uses-clause a "long time ago", but i admit: didn't know that you can't/shouldn't use those two together.
Maybe put that on the HeapTrc-Wiki: DON'T USE IT WITH ANY OTHER MEMORY-MANAGER.

The above problems can be wholly caused by mixing two different memory managers, so try first heaptrc without cmem and then with just cmem and without the heaptrc option set.
If there is still memory corruption we need to look further.

The reason I suspect this is the case is the following:
When the compiler inserts heaptrc it does so *before* anything else is done and heaptrc already allocates memory by itself to be able to register all memory allocations/de-allocations. (that's why it is done by the compiler! and not through a uses clause)
That memory is lost when you subsequently set a different memory manager: acute memory corruption.

EDIT: Another thing i don't understand: The Error-Message i'm getting implies a problem with the linker.
But both, the library and the Test-Program compile without hitches, and the linker throws the error, when it reaches the point in the code as described above.
Funny thing: only with SQLite. A single thread accessing MySQl works (2/more threads accessing MySQL is another can of worms).

The library is accessed during runtime via the exported functions (lib is not statically linked into the main program)

[Cyrax]

Open a terminal; issue these commands and check how high is the stack size set in Ubuntu system.

#soft limits for a process/thread
ulimit -a
#hard limits for a process/thread
ulimit -Ha

Then set the soft limit of a stack size for reasonable size eg. 512 (ulimit -s 512) and try to re-execute your program.

[Thaddy]

I have tried to replicate your problem on win64 and Raspbian, but I used 3.2.0 and 3.3.1 (from today).
I have no problem using sqlite3 in any way, whatever memory manager I use.
Note that the Sqlite3 bindings in 3.2.0 and trunk have changed a bit to support threading in a better way.

[Zvoni]

I have tried to replicate your problem on win64 and Raspbian, but I used 3.2.0 and 3.3.1 (from today).
I have no problem using sqlite3 in any way, whatever memory manager I use.
Note that the Sqlite3 bindings in 3.2.0 and trunk have changed a bit to support threading in a better way.

Thaddy,
thx for that information. I'll postpone on SQLite-use until second half of the year then, when FPC320 becomes officially available
(not familiar with building from svn/trunk/wherever)

[Zvoni]

Open a terminal; issue these commands and check how high is the stack size set in Ubuntu system.

#soft limits for a process/thread
ulimit -a
#hard limits for a process/thread
ulimit -Ha

Then set the soft limit of a stack size for reasonable size eg. 512 (ulimit -s 512) and try to re-execute your program.

thx, will try that and report back

[Cyrax]

I have tried to replicate your problem on win64 and Raspbian, but I used 3.2.0 and 3.3.1 (from today).
I have no problem using sqlite3 in any way, whatever memory manager I use.
Note that the Sqlite3 bindings in 3.2.0 and trunk have changed a bit to support threading in a better way.

Thaddy,
thx for that information. I'll postpone on SQLite-use until second half of the year then, when FPC320 becomes officially available
(not familiar with building from svn/trunk/wherever)

You can use fpcupdeluxe for that : http://wiki.lazarus.freepascal.org/fpcupdeluxe

[Zvoni]

Open a terminal; issue these commands and check how high is the stack size set in Ubuntu system.

#soft limits for a process/thread
ulimit -a
#hard limits for a process/thread
ulimit -Ha

Then set the soft limit of a stack size for reasonable size eg. 512 (ulimit -s 512) and try to re-execute your program.

thx, will try that and report back

My result on my machine

Code: [Select]

zvoni@ZvoniLinux:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31133
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31133
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
zvoni@ZvoniLinux:~$ ulimit -Ha
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31133
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31133
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited


[Thaddy]

Maybe put that on the HeapTrc-Wiki: DON'T USE IT WITH ANY OTHER MEMORY-MANAGER.

FYI: I just adapted the wiki and added a warning, but also a note how to handle alternative memory managers and heaptrc in the same codebase:
http://wiki.freepascal.org/heaptrc
http://wiki.freepascal.org/heaptrc#Why_heaptrc_should_not_be_added_to_the_uses_clause_manually

[Cyrax]

Open a terminal; issue these commands and check how high is the stack size set in Ubuntu system.

#soft limits for a process/thread
ulimit -a
#hard limits for a process/thread
ulimit -Ha

Then set the soft limit of a stack size for reasonable size eg. 512 (ulimit -s 512) and try to re-execute your program.

thx, will try that and report back

My result on my machine

Code: [Select]

zvoni@ZvoniLinux:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31133
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31133
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
zvoni@ZvoniLinux:~$ ulimit -Ha
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31133
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31133
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited


What does ulimit -Ha say?

[Zvoni]

Code: [Select]

zvoni@ZvoniLinux:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31133
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31133
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
zvoni@ZvoniLinux:~$ ulimit -Ha

Code: [Select]

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31133
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31133
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

What does ulimit -Ha say?

huh?

[Zvoni]

Maybe put that on the HeapTrc-Wiki: DON'T USE IT WITH ANY OTHER MEMORY-MANAGER.

FYI: I just adapted the wiki and added a warning, but also a note how to handle alternative memory managers and heaptrc in the same codebase:
http://wiki.freepascal.org/heaptrc
http://wiki.freepascal.org/heaptrc#Why_heaptrc_should_not_be_added_to_the_uses_clause_manually

Thaddy, thx
+1

[Cyrax]

Code: [Select]

zvoni@ZvoniLinux:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31133
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31133
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
zvoni@ZvoniLinux:~$ ulimit -Ha

Code: [Select]

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31133
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31133
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

What does ulimit -Ha say?

huh?

Oh sorry, I didn't see the ulimit -Ha part from the quote text field. 

It seems there is no limits. Please open a terminal in your program directory, execute ulimit -s 512 and then execute your program and see if there is errors or program misbehaves .

EDIT : Oh, there is soft limit:

stack size              (kbytes, -s) 8192

[Zvoni]

Oh sorry, I didn't see the ulimit -Ha part from the quote text field. 

It seems there is no limits. Please open a terminal in your program directory, execute ulimit -s 512 and then execute your program and see if there is errors or program misbehaves .

Definitely no expert here, but why should i lower my Stack-size from 8196 KB to 512? (ulimit -s is for the "soft"-limit?!)