2010/2/3 Przemysław Czerpak :
> 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 the same item w
2010/2/3 Przemysław Czerpak :
> 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 hbthread.ch and cod
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" ) )
> xRe
2010/2/3 Przemysław Czerpak :
> 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 !empty( pHRB := hb_h
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
2010/2/3 Przemysław Czerpak :
> 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 is used.
Here
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
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:
> 2
2010/2/2 Przemysław Czerpak :
> 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 0xb7a446d0 in raise ()
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 insta
2010/2/2 Przemysław Czerpak :
> 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
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
On Tue, Feb 2, 2010 at 7:25 PM, Viktor Szakáts 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)
Harbour@harbour-project.org
http:
>> 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 PGcan
2010/2/2 Przemysław Czerpak :
> 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
> G
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 re
2010/2/2 Przemysław Czerpak :
> 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 command-line
option -
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]
> /lib/tls/i686/cmov/libc.so.6(cfree+0
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]
/usr/lib/libpq.so.5(PQclear+0x30)[0xb7b88420]
19 matches
Mail list logo
