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: > 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 0xb7a446d0 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7a46098 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7a8224d in ?? () from /lib/tls/i686/cmov/libc.so.6 > #4 0xb7a88604 in ?? () from /lib/tls/i686/cmov/libc.so.6 > #5 0xb7a8c04d in ?? () from /lib/tls/i686/cmov/libc.so.6 > #6 0xb7a8cee6 in realloc () from /lib/tls/i686/cmov/libc.so.6 > #7 0xb7d0ea3b in hb_xrealloc (pMem=0x87e69ac, ulSize=1024) > at ../../../../fm.c:843 > #8 0xb7d1052b in hb_hashResize (pBaseHash=0xa, ulNewSize=6) > at ../../../../hashes.c:271 > #9 0xb7d32f07 in hb_hashValuePtr (pBaseHash=0x87d8dc4, pKey=0x87e09ec, > fAdd=1) > at ../../../../hashes.c:307 > #10 0xb7d330cc in hb_hashGetItemPtr (pHash=0x87ee104, pKey=0x87e09ec, > iFlags=2) > at ../../../../hashes.c:470 > #11 0xb7d411d4 in hb_vmArrayPop () at ../../../../hvm.c:5221 > #12 0xb7d1c9a3 in hb_vmExecute (pCode=0xb804bb50 "\002$\001\0010^", > pSymbols=0xb8055f20) at ../../../../hvm.c:1576 > ... > > best regards, > Lorenzo > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
