2010/2/3 Przemysław Czerpak dru...@acn.waw.pl:
See MULTI THREAD SUPPORT in doc/xhb-diff.txt. I documented shared
and inherited thread resources in Harbour.
Many thanks it SOLVED it.
The key part is:
---
In practice the only one not synced automatically element in Harbour
is write access to
2010/2/2 Przemysław Czerpak dru...@acn.waw.pl:
If you want to see information about source file names and line numbers
then just like for GDB do not strip final binaries and compile Harbour
code with -g GCC flag.
Sorry probably I miss sth.
I've rebuilt Harbour ( 13750 ) with -g and I did a
Hi,
Lorenzo Fiorini wrote:
If you want to see information about source file names and line numbers
then just like for GDB do not strip final binaries and compile Harbour
code with -g GCC flag.
Sorry probably I miss sth.
I've rebuilt Harbour ( 13750 ) with -g and I did a make clean make
2010/2/2 Przemysław Czerpak dru...@acn.waw.pl:
If you want to see information about source file names and line numbers
then just like for GDB do not strip final binaries and compile Harbour
code with -g GCC flag.
At last I got a bt
(gdb) bt
#0 0xb8096430 in __kernel_vsyscall ()
#1
I think we'd need a self-contained example here.
I tried to check the valgrind log, but the code
running is non-Harbour .c code, so it not very easy
to draw any conclusions, it could basically be
anything corrupting internals.
Brgds,
Viktor
On 2010 Feb 3, at 16:43, Lorenzo Fiorini wrote:
On Wed, 03 Feb 2010, Lorenzo Fiorini wrote:
Hi,
Try to use valgrind instead of GDB to detect memory corruption.
Attached the valgrind log.
==30772== Invalid read of size 1
==30772==at 0x41A7121: hb_vmExecute (hvm.c:1231)
[...]
==30772== Address 0x52794e3 is 35 bytes inside a block of
2010/2/3 Przemysław Czerpak dru...@acn.waw.pl:
You are freeing directly or indirectly HRB module which is currently
executed. HRB modules are unloaded automatically when all references to
pHRB variable returned by hb_hrbLoad() are cleared.
Fix you code to keep HRB module alive as long as it
On Wed, 03 Feb 2010, Lorenzo Fiorini wrote:
You are freeing directly or indirectly HRB module which is currently
executed. HRB modules are unloaded automatically when all references to
pHRB variable returned by hb_hrbLoad() are cleared.
Fix you code to keep HRB module alive as long as it
2010/2/3 Przemysław Czerpak dru...@acn.waw.pl:
or simply migrate to static functions only. You can use
I can do it since all the HRBs have the same func name and I can change it.
Here is the final code:
begin sequence with { |e| logerror( e, oResponse, cBinFile ) }
if
On Wed, 03 Feb 2010, Lorenzo Fiorini wrote:
Here is the final code:
begin sequence with { |e| logerror( e, oResponse, cBinFile ) }
if !empty( pHRB := hb_hrbload( cBinFile ) )
if !empty( sFunc := hb_hrbGetFunSym( pHRB, HRBMAIN ) )
xResult
2010/2/3 Przemysław Czerpak dru...@acn.waw.pl:
No. By default all memvars (PUBLIC and PRIVATE) variables are separated
between threads and each threads starts with its own clean set of memvars.
If you want to change it then you can use thread attributes in
hb_threadStart() function. See
On Mon, 01 Feb 2010, Lorenzo Fiorini wrote:
Hi,
Continuing in my MT path this is what I get from code that work since years
ST:
double free or corruption (!prev): 0x0a05bd48 ***
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6[0xb7a89604]
2010/2/2 Przemysław Czerpak dru...@acn.waw.pl:
Check if libpq is fully MT safe.
Thanks for the answer. This is what I've found in
http://www.enterprisedb.com/documentation/libpq-concepts.html:
...
29.4.16. Behavior in Threaded Programs
libpq is reentrant and thread-safe if the configure
On Tue, 02 Feb 2010, Lorenzo Fiorini wrote:
Thanks for the answer. This is what I've found in
http://www.enterprisedb.com/documentation/libpq-concepts.html:
[...]
Do you think I can found not thread-safe libpq in distros like Centos,
Fedora, Ubuntu?
Add Harbour wrapper to function which
2010/2/2 Przemysław Czerpak dru...@acn.waw.pl:
Add Harbour wrapper to function which returns thread safe status
and check it. And of course check if you are using new separate
concatenation in each thread in your own code.
Ok, I'll check it.
BTW someone should update
Add Harbour wrapper to function which returns thread safe status
and check it. And of course check if you are using new separate
concatenation in each thread in your own code.
Ok, I'll check it.
BTW someone should update contrib/hbpgsql/postgres.c to use
GC pointers for PGcancel* and
On Tue, Feb 2, 2010 at 7:25 PM, Viktor Szakáts harbour...@syenar.hu wrote:
Ops, I've already started it.
No problem, you can surely do it better.
Many thanks.
best regards,
Lorenzo
___
Harbour mailing list (attachment size limit: 40KB)
On Tue, 02 Feb 2010, Lorenzo Fiorini wrote:
BTW did you see my msg Help with segfaults with MT and hb_hrbload?
I've created a test with pure prg code but I still get random errors.
Any suggestion?
Use valgrind to locate the problem.
Such random GPFs can be results of memory corruptions by some
Continuing in my MT path this is what I get from code that work since years ST:
double free or corruption (!prev): 0x0a05bd48 ***
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6[0xb7a89604]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7a8b5b6]
19 matches
Mail list logo
