Here's one with MinGW 4.4.0 on Windows:
(this was built with 'set HB_BUILD_DEBUG=yes')
---
Program received signal SIGSEGV, Segmentation fault.
hb_rddFieldGet (pItem=0x1aa4954, pFieldSymbol=0xa094c0) at ../../wafunc.c:479
479 if( ( PHB_DYNS ) pField->sym == pDynSym )
(gdb) bt
#0 hb_rddFieldGet (pItem=0x1aa4954, pFieldSymbol=0xa094c0) at
../../wafunc.c:479
#1 0x007b7dd6 in hb_vmPushVariable (pVarSymb=0xa094c0) at ../../hvm.c:6974
#2 0x007a5bef in hb_vmExecute (pCode=0x1ec20ef "\f\...@─oĘ\001h\a
ý\001 ý\001", pSymbols=0x0) at ../../hvm.c:2674
#3 0x007e43c5 in hb_vmEvalBlockOrMacro (pItem=0x1ec22fc) at ../../macro.c:203
#4 0x008197f8 in hb_cdxTagLoad (pTag=0x1ec1f7c) at ../../dbfcdx1.c:3668
#5 0x008205c9 in hb_cdxTagNew (pIndex=0x1ec12dc, szTagName=<value
optimized out>, TagHdr=3) at ../../dbfcdx1.c:3767
#6 0x008246fe in hb_cdxIndexLoad (pIndex=0x1ec12dc, szBaseName=<value
optimized out>) at ../../dbfcdx1.c:4936
#7 0x00824a29 in hb_cdxOrderListAdd (pArea=0x1ec069c,
pOrderInfo=0x22f9e8) at ../../dbfcdx1.c:7353
#8 0x00818366 in hb_cdxOpen (pArea=0x1ec069c, pOpenInfo=0x22fa60) at
../../dbfcdx1.c:7182
#9 0x007fa495 in hb_rddOpenTable (szFileName=0x1ec063c
"C:\\work\\ep\\data\\[...snip...]\\d_fs.dbf", szDriver=0x0,
uiArea=<value optimized out>, szAlias=0xb4d33a "w_FSZLTET",
fShared=1, fReadonly=0, szCpId=0x0, ulConnection=0, pStruct=0x0,
pDelim=0x0) at ../../wafunc.c:664
#10 0x007f34ac in HB_FUN_DBUSEAREA () at ../../dbcmd.c:895
#11 0x007e09e2 in hb_vmProc (uiParams=6) at ../../hvm.c:5693
#12 0x007e155b in hb_xvmDo (uiParams=6) at ../../hvm.c:8796
#13 0x004a9a08 in HB_FUN_DBFOPEN ()
---
Brgds,
Viktor
On Mon, Jun 29, 2009 at 2:23 PM, Viktor Szakáts<[email protected]> wrote:
> Not much closer I guess after switching to plain -g.
>
> [ BTW, I'm doing these traces on Darwin x86, so there was no
> -fomit-frame-pointer
> switch here. All what's changed now is missing TRACE calls. ]
>
> ---
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0000d5a2
> hb_gcItemRef (pItem=0xc6d8e4) at garbage.c:518
> 518 pAlloc->used ^= HB_GC_USED_FLAG;
> (gdb) bt
> #0 hb_gcItemRef (pItem=0xc6d8e4) at garbage.c:518
> #1 0x002b536e in hb_gcItemRef (pItem=<value temporarily unavailable, due to
> optimizations>) at garbage.c:524
> #2 0x002b536e in hb_gcItemRef (pItem=<value temporarily unavailable, due to
> optimizations>) at garbage.c:524
> #3 0x002b54db in hb_gcItemRef (pItem=<value temporarily unavailable, due to
> optimizations>) at hashes.c:99
> #4 0x002b536e in hb_gcItemRef (pItem=<value temporarily unavailable, due to
> optimizations>) at garbage.c:524
> #5 0x002b5518 in hb_stackMemvarScan (pDynSymbol=0x1, Cargo=0x0) at
> estack.c:1208
> #6 0x002b560d in hb_dynsymEval [inlined] () at dynsym.c:554
> #7 0x002b560d in hb_stackIsMemvarRef [inlined] () at estack.c:1240
> #8 0x002b560d in hb_stackIsStackRef (pStackId=0x8f5160, pCleanFunc=0) at
> dynsym.c:1284
> #9 0x002b571b in hb_gcCollectAll (fForce=0) at hvm.c:11285
> #10 0x003819bc in hb_idleState () at ../../idle.c:194
> #11 0x00381b0f in hb_idleSleep (dSeconds=0.5) at ../../idle.c:232
> #12 0x00381b4a in HB_FUN_HB_IDLESLEEP () at ../../idle.c:255
> #13 0x002f5812 in hb_vmProc (uiParams=49386) at hvm.c:5693
> #14 0x002f6199 in hb_xvmDo (uiParams=1) at hvm.c:8796
> [...snipped local lib and app code...]
> #24 0x00008335 in HB_FUN_MAIN () at .hbmk/darwin/gcc/ap_main.c:1421
> #25 0x002f5812 in hb_vmProc (uiParams=0) at hvm.c:5693
> #26 0x002ff794 in main (argc=1, argv=0x1) at mainstd.c:88
> (gdb)
> ---
>
> Brgds,
> Viktor
>
> On 2009.06.29., at 14:00, Przemyslaw Czerpak wrote:
>
>> On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
>>> hb_dynsymName (pDynSym=0xd5ddb4) at dynsym.c:463
>>> 463 HB_TRACE(HB_TR_DEBUG, ("hb_dynsymName(%p)", pDynSym));
>>
>> GDB shows line where it cannot GPF so I guess it's a problem with
>> line numbers or stripped frame pointer by -fomit-frame-pointer.
>> Please rebuild Harbour with -g compiler switch and without
>> -fomit-frame-pointer but with all other default switches to replicate
>> default build and runtime conditions as close as possible and repeat
>> above test.
>>
>> best regards,
>> Przemek
>> _______________________________________________
>> Harbour mailing list
>> [email protected]
>> http://lists.harbour-project.org/mailman/listinfo/harbour
>
>
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
