Miguel,

Sure, but I never encountered any such problem - do you have any self 
contained sample that will show such GPF?

Ron

--------------------------------------------------
From: "Miguel Angel Marchuet" <miguelan...@marchuet.net>
Sent: Thursday, January 15, 2009 8:12 AM
To: "Ron Pinkas" <ron.pin...@xharbour.com>; "xharbour developer list" 
<xharbour-developers@lists.sourceforge.net>
Subject: Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 
MiguelAngelMarchuet<miguelan...@marchuet.net>

> there are 26509 calls to hb_xgrab, hb_xrealloc previous hx_xinit
>
> the debuguer colapse my machine, please can you find this calls ;)
> to situate in a better place the call to hb_xinit()
>
> Best regards,
> Miguel Angel Marchuet
>
> Ron Pinkas escribió:
>> Miguel,
>>
>> It's very easy to find and fix, simply add:
>>
>>    assert( hProcessHeap );
>>
>> Then build with debug info, and you'll get the exact line and call stack 
>> leading to the failed assert.
>>
>> Here's my settings for MSVC debug build:
>>
>> SET CFLAGS=/Od /EHsc /RTC1 /MTd /Gs /GS /Gy /GR /Zi /DHB_FM_STATISTICS 
>> /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE
>>
>> SET LFLAGS=-DEBUG -DEBUGTYPE:CV
>>
>> Ron
>>
>>
>> --------------------------------------------------
>> From: "Miguel Angel Marchuet Frutos" <miguelmarch...@gmail.com>
>> Sent: Wednesday, January 14, 2009 10:40 AM
>> To: "Ron Pinkas" <ron.pin...@xharbour.com>
>> Cc: "xharbour developer list" <xharbour-developers@lists.sourceforge.net>
>> Subject: Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 Miguel 
>> AngelMarchuet <miguelan...@marchuet.net>
>>
>>> I don't tested exctly where is called fm.api but if i remove the 
>>> protection
>>>
>>> change:
>>>
>>> #     define malloc( n )      ( void * ) HeapAlloc( ( hProcessHeap ? 
>>> hProcessHeap : GetProcessHeap() ), 0, ( n ) )
>>> #     define realloc( p, n )  ( void * ) HeapReAlloc( ( hProcessHeap ? 
>>> hProcessHeap : GetProcessHeap() ), 0, ( void * ) ( p ), ( n ) )
>>> #     define free( p )        HeapFree( ( hProcessHeap ? hProcessHeap : 
>>> GetProcessHeap() ), 0, ( void * ) ( p ) )
>>>
>>> with:
>>>
>>> #     define malloc( n )      ( void * ) HeapAlloc( hProcessHeap, 0, ( 
>>> n ) )
>>> #     define realloc( p, n )  ( void * ) HeapReAlloc( hProcessHeap, 0, 
>>> ( void * ) ( p ), ( n ) )
>>> #     define free( p )        HeapFree( hProcessHeap, 0, ( void * ) ( 
>>> p ) )
>>>
>>> then GPF is produced because there are a call to hb_xalloc or 
>>> hb_xrealloc previous to hb_xinit. Harbour has the same problem
>>> for this reason prezmek needt to protect too.
>>>
>>> But i want to remove this protection.
>>>
>>> Can you say me how to build xharbour with debug info for mscv8 ?
>>>
>>> I'm evaluating too to create a process heap for each thread to eliminate 
>>> some locks at MT.
>>>
>>> Best regards
>>> Miguel Angel Marchuet
>>>
>>> Ron Pinkas escribió:
>>>> Miguel,
>>>>
>>>> WHERE do we use fm api before it's initialized?
>>>>
>>>> Ron
>>>>
>>>> --------------------------------------------------
>>>> From: "Miguel Angel Marchuet" <miguelan...@marchuet.net>
>>>> Sent: Wednesday, January 14, 2009 2:48 AM
>>>> To: "xharbour developer list" 
>>>> <xharbour-developers@lists.sourceforge.net>
>>>> Subject: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 Miguel 
>>>> AngelMarchuet <miguelan...@marchuet.net>
>>>>
>>>>> 2009-01-14 11:34 UTC+0100 Miguel Angel Marchuet 
>>>>> <miguelan...@marchuet.net>
>>>>>   * source\vm\fm.c
>>>>>     ! minor optimization, 1 seg more quick speedtst, but remains one 
>>>>> important question
>>>>>       fmapi is used before its initialization (void hb_xinit( void )) 
>>>>> I think this function
>>>>>       need be called first of all.
>>>>>     - removed test comments.
>>>>>     + Added macro HB_FM_LOCALALLOC to use LocalAlloc instead of 
>>>>> HeapAlloc. Microsoft says that
>>>>>       the use of LocalAlloc need be changed by HeapAlloc, but we leave 
>>>>> it here to user election.
>>>>>
>>>>> Best regards,
>>>>> Miguel Angel Marchuet
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> This SF.net email is sponsored by:
>>>>> SourcForge Community
>>>>> SourceForge wants to tell your story.
>>>>> http://p.sf.net/sfu/sf-spreadtheword
>>>>> _______________________________________________
>>>>> xHarbour-developers mailing list
>>>>> xHarbour-developers@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/xharbour-developers
>>>>>
>>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> xHarbour-developers mailing list
>> xHarbour-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/xharbour-developers
>>
>> __________ Información de ESET NOD32 Antivirus, versión de la base de 
>> firmas de virus 3767 (20090115) __________
>>
>> ESET NOD32 Antivirus ha comprobado este mensaje.
>>
>> http://www.eset.com
>>
>>
>>
>>
>
> 

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers

Reply via email to